Subject: RE: Extending IPCP for Route Table Entries

From: Doug Kehn <[email-masked]>
Date: Mon, 12 May 2003 17:25:21 -0500

Vernon,

I agree with your comments.  However, most service providers don't use the
available routing protocols (???).  I believe it would be okay to "put our
collective feet down and stop allowing such bad ideas."  But until it is
done so publicly, rogue protocol extensions may prevail (i.e. I've yet to
find an RFC for IPCP option 144).

My goal was to come up with an admissible solution/compromise at the PPP
layer or to have the working group put its foot and say no.  I would hate
for another non-IETF sanctioned protocol extension prevail.

I've included the draft-carrel-info-pppoe-ext-00.txt for your review.

...doug

PPP Working Group                              David Carrel, Dan Simone,
INTERNET DRAFT                                    Che-Lin Ho, Tom Stoner
Category: Informational                           Redback Networks, Inc.
Title: draft-carrel-info-pppoe-ext-00.txt
Date: May 2000

   Extensions to a Method for Transmitting PPP Over Ethernet (PPPoE)
                  <draft-carrel-info-pppoe-ext-00.txt>

                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   carrel-info-pppoe-ext-00.txt>, and expires 30 November, 2000.  Please
   send comments to the authors.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
   PPPoE [2] describes how to build PPP sessions and encapsulate PPP
   packets over Ethernet.

   This document describes extensions to PPPoE.  These extensions
   provide added functionality, but are optional and preserve
   compatibility.

Carrel                                                  	[Page1]

INTERNET DRAFT                                                  May 2000

1. Introduction

   PPP over Ethernet (PPPoE) [2] provides the ability to connect a
   network of hosts over a simple Ethernet bridging access device to a
   remote Access Concentrator.  With this model, each host utilizes it's
   own PPP stack and the user is presented with a familiar user
   interface.  Access control, billing and type of service can be done
   on a per-user, rather than a per-site, basis.

   The flexibility provided by PPPoE has inspired the development of
   several extensions to the protocol.  These extensions provide for
   networking level enhancements as well as session level enhancements
   aimed at the user experience.  These enhancements maintain backwards
   compatibility with the core PPPoE protocol.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [3].

3. Discovery Stage

   The PADI, PADO, PADR, PADS and PADT defined in [2] are unchanged.
   The following discovery packets have been added.  Since this is the
   Discovery Stage, an ETHER_TYPE of 0x8863 MUST be used.

3.1 The PPPoE Active Discovery Message (PADM) packet

   An Access Concentrator MAY send a PADM at any time while a session is
   active to convey informational messages to the Host.  The
   DESTINATION_ADDR is the unicast address of the Host.  The CODE field
   is set to 0xd3 and the SESSION_ID MUST be set to the current (active)
   SESSION_ID value.

   Use of this packet is optional for both the Access Concentrator and
   the Host.  A PADM packet MUST contain at least one TAG of type HURL
   or MOTM and SHOULD NOT contain any other TAGs.  Additional messaging
   TAGs may be defined in the future that are appropriate for PADM
   packets.

Carrel                                                  	[Page2]

INTERNET DRAFT                                                  May 2000

3.2 The PPPoE Active Discovery Network (PADN) packet

   An Access Concentrator MAY send a PADN at any time while a session is
   active to convey network level information to the Host.  The
   DESTINATION_ADDR is the unicast address of the Host.  The CODE field
   is set to 0xd4 and the SESSION_ID MUST be set to the current (active)
   SESSION_ID value.

   An Access Concentrator SHOULD send a PADN as soon as possible after
   an NCP completes negotiation.  That PADN SHOULD only contain TAGs
   that are appropriate for that NCP.  Since there is no limit on the
   number of PADNs that may be sent, it is appropriate to send a PADN
   for each NCP.

   Use of this packet is optional for both the Access Concentrator and
   the Host, though in general it is expected that it will only be sent
   by the Access Concentrator.  A PADN packet MUST contain at least one
   TAG of type IP_ROUTE_ADD and SHOULD NOT contain any other TAGs.
   Additional network TAGs may be defined in the future that are
   appropriate for PADN packets.

4. PPPoE Clarifications

   Since publication of [2], discussions have taken place which have
   identified some areas of ambiguity.  To avoid confusion and inter-
   operability problems, we are providing further clarification.  This
   is a clarification of [2] and does not change [2] in any way.

Carrel                                                  	[Page3]

INTERNET DRAFT                                                  May 2000

4.1 Service Selection

   Service Selection is a key feature of PPPoE.  It allows for the Host
   to request a specific service and it also allows for the Access
   Concentrator to "advertise" a list of services.  Service Selection is
   optional, but if the Host and Access Concentrator wish to participate
   in it, they should operate as indicated below.  User Interface (UI)
   issues are discussed as well.

   If either the Host or Access Concentrator does not wish to
   participate in Service Selection, then they SHOULD use a Service-Name
   TAG with zero length, indicating that any service is acceptable.
   This can be done in the PADI, PADO, PADR and PADS packets to indicate
   that PPPoE Service Selection is not being used and PPP authentication
   should be used to determine the user's "service".  In this case, no
   UI is needed beyond the PPP UI.

   Occasionally the Host will know in advance that it wishes to use a
   specific PPPoE Service.  In that case, it MAY put that service in a
   Service-Name TAG in both the PADI and PADR.  For this case, the UI
   should allow the Service-Name to be specified prior to beginning
   PPPoE Discovery.  Our anticipation is that this case will be very
   rare.  Since PPPoE has no security, Service Selection should be
   considered informational.  PPP Authentication can be trusted and
   should be used to identify the user when there is no desire to
   "discover" services.

   Dynamic Service Selection happens when the Host wishes to "discover"
   what services are out there.  The Host does not put a specific
   Service-Name value in the PADI and waits for a list of Service-Name
   TAGs from the Access Concentrator(s).  This is accomplished by
   sending a PADI with a zero length Service-Name TAG.  This indicates
   that the Host is trying to discover all services that are available.
   Each Access-Concentrator MAY then reply with a PADO listing multiple
   services.  If the Host is capable of doing Service Selection, it
   SHOULD send a PADI and receive the PADO(s) before accepting any user
   input.  It SHOULD then present the list of Services to the user and
   wait for the user to select one prior to sending the PADR.  The PADR
   is the point where the Host "selects" its service.  The UI should
   display the list of discovered Services.  As an added value, it could
   remember commonly chosen Services and could even remember the last
   PPP username used for each Service.  The Host MUST remember which
   Access Concentrator sent which Service-Name TAGs so that the PADR is
   sent to the correct Access Concentrator.

Carrel                                                  	[Page4]

INTERNET DRAFT                                                  May 2000

5. PPP Considerations

   PADM packets SHOULD be sent after PPP authentication has completed in
   order to provide per-user messaging.  Also PADM packets containing
   HURL TAGs SHOULD be sent after an NCP is established so that network
   connectivity is available for the web browser.  However a Host
   implementation MUST be able to receive one at any time after PPPoE
   session establishment.

6. Security Considerations

   All data confidentiality and authenticity issues are left to higher
   layers such as PPP or IP.  As such, any information sent in a PADM
   packet can not be protected.  To present data to a user in a secure
   manner, HURLs can be used to establish a connection over higher
   layers that do provide security.  Service Selection is NOT secure and
   should only be used informationally.

7. Acknowledgments

   Copious amounts of text were stolen from RFC 2516.

8. References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
   1661, July 1994

   [2] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet
   (PPPoE)", RFC 2516, February 1999

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
   2279, January 1998.

   [5] Berners-Lee, T., Masinter, L., and McCahill, M.  "Uniform
   Resource Locators (URL)", RFC 1738, December 1994

Carrel                                                  	[Page5]

INTERNET DRAFT                                                  May 2000

Appendix A

   TAG_TYPES and TAG_VALUES

   0x0111 HURL

      This TAG MAY be added to PADM packets by the Access Concentrator.
      It contains a URL that the Host MAY pass to a web browser for
      presentation to the user.  The TAG_VALUE contains a standard URL
      [5].  It is an UTF-8 string which is not NULL terminated.

   0x0112 MOTM

      This TAG MAY be added to PADM packets by the Access Concentrator.
      It contains a Message Of The Minute (MOTM) that the Host MAY
      display to the user.  The TAG_VALUE contains an UTF-8 string which
      is not NULL terminated.  It is a text message that is presentable
      to the user on the Host.

   0x0121 IP_ROUTE_ADD

      This TAG MAY be added to PADN packets by the Access Concentrator.
      It contains a IP route that MAY be used by the Host to populate
      it's routing table.  The behavior of PPP is not defined in terms
      of what routes should be installed if multiple concurrent PPP
      sessions exist.  Many client implementations will install a
      default route but that only works if one PPP session is active.
      When multiple PPPoE sessions are active, the IP_ROUTE_ADD TAG can
      provide a more granular set of routes to the client.  The
      TAG_VALUE contains four 32 bit integers in network byte order.
      The first integer contains a destination network number and the
      second contains a destination network mask.  The third integer
      contains the gateway IP address.  The fourth integer contains a
      metric value.  The destination of the route is always assumed to
      be the remote end of the PPP link.  If the first two integers are
      zero this indicates a default route.  In general the gateway IP
      address will be the same as the Access Concentrator's IP address
      on that PPP session, because use of this tag is only intended to
      provide routing information about the first hop (ie. which PPP
      interface the client should use).  Any routes installed as a
      result of the IP_ROUTE_ADD TAG being received, SHOULD be removed
      when the PPPoE session terminates.

Carrel                                                  	[Page6]

INTERNET DRAFT                                                  May 2000

Appendix B

   The following are some example packets:

   A PADM packet:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Host_mac_addr                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Access_Concentrator_mac_addr (cont)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0xd3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SESSION_ID = 0xNNNN       |      LENGTH = 0x001a          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0111        |    TAG_LENGTH = 0x0016        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x68      |     0x74      |     0x74      |     0x70      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x3a      |     0x2f      |     0x2f      |     0x77      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x77      |     0x77      |     0x2e      |     0x72      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x65      |     0x64      |     0x62      |     0x61      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x63      |     0x6b      |     0x2e      |     0x63      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x6f      |     0x6d      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Carrel                                                  	[Page7]

INTERNET DRAFT                                                  May 2000

   A PADN packet: This contains two IP_ROUTE_ADD TAGs.  The first is the
   route "10.1.1.0 255.255.255.0".  The second is "20.2.0.0
   255.255.0.0".  The Access Concentrator's IP address for the PPPoE
   session is 10.1.1.1.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Host_mac_addr                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Access_Concentrator_mac_addr (cont)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0xd4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SESSION_ID = 0xNNNN       |      LENGTH = 0x0028          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0121        |    TAG_LENGTH = 0x0010        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010100                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0xffffff00                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010101                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x00000001                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0121        |    TAG_LENGTH = 0x0010        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x14020000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0xffff0000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010101                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x00000001                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Carrel                                                  	[Page8]

INTERNET DRAFT                                                  May 2000

Authors' Addresses:

   David Carrel <[email-masked]>
   Dan Simone <[email-masked]>
   Che-Lin Ho <[email-masked]>
   Tom Stoner <[email-masked]>
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA  95134
   United States of America

Carrel                                                  	[Page9]

-----Original Message-----
From: Vernon Schryver
To: [email-masked]
Sent: 5/12/03 4:45 PM
Subject: Re: Extending IPCP  for Route Table Entries

> From: Doug Kehn <[email-masked]>

> I would like to open a discussion on the possibilities for extending
IPCP to
> allow the negotiation of route table entries.  The topic of adding
route
> information to PPP has been brought up in the DSL Forum.  However, to
the
> best of my knowledge, the DSL Forum has not approached the IETF
regarding
> this topic.  Currently, some PPPoE capable BRASs have implemented PADN
(see
> draft-carrel-info-pppoe-ext-00.txt) as a way a add route information
over
> PPP links.  This facility only suffices the need for PPPoE links.  A
more
> general approach would be to extend PPP itself.  To jump start the
> discussion, I've included a draft RFC (see below) that oulines a
method for
> extending IPCP that might be used to fulfill the need.

Let's put our collective feet down and stop allowing such bad ideas.
It makes no sense to extend IPCP to carry routes.  There are plenty
of existing standards for that.  For example, you could do what has
been done for literally decades and use RIP.  You could even use
authentication in RIPv2.  If you don't like RIP, you can use
Router-Discovery, OSPF, BGP, and a zillion other routing protocols.

I can't seem to find draft-carrel-info-pppoe-ext-00.txt or anything
with the string "carrel" on ftp.isi.edu.

Vernon Schryver    [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 15:14:42 -0700 (PDT)

> find an RFC for IPCP option 144).

I believe that "putting our collective feet down" would require a change
in the IANA allocations policy for IPCP code points. Today this is "first
come first served", no?

We now have the following proposals for (additional) uses of IPCP:

http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt
http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 12 May 2003 19:27:54 -0600 (MDT)

> available routing protocols (???). 

On the contrary, almost all service providers use the available routing
protocols somewhere, even if not on their end-user PPP links.  What
hardware can't announce a RIP route?  What hardware that might support
such a new option could not at least as easily synthesize a RIP
announcement.  

>                                     I believe it would be okay to "put our

An RFC saying "STOP BEING STUPID" would be a good idea.

> I've included the draft-carrel-info-pppoe-ext-00.txt for your review.

sheesh...
The May 2000 date of that draft gives me a little hope that it got
squelched outside Redback's customers.  It was "Informational."

Among the problems with putting routing into IPCP is that it is
cannot advertise the route more than once, because you really don't
want to re-negotiate IPCP more than once, because so much of this
drek hardware is junk and cannot.

But if you only announce the route once, then you may as well do
what PPP implementations have done since before there was PPP and
there was only SLIP.  That is to install a default route to the PPP
(or SLIP) peer.

    ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

] From: Bernard Aboba <[email-masked]>

] ...
] I believe that "putting our collective feet down" would require a change
] in the IANA allocations policy for IPCP code points. Today this is "first
] come first served", no?

Why do you say that IPCP types are "first come first served"?  I
thought we fixed that problem that a long time ago.
On http://www.iana.org/numbers.html I see something about ordering
PPP protocol numbers, but nothing about IPCP.

] We now have the following proposals for (additional) uses of IPCP:
]
] http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt
] http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt
] http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt

The IPv6 DNS extension is a mistake, but probably forced on us because
we failed to stop Microsoft from perpetrating the IPv4 predecessor.
The other two have expired and are about to expire.  Why are those
other two drafts more persuasive or "standard" than the following:

http://www.ietf.org/internet-drafts/draft-terrell-iptx-dns-req-iptx-ip-add-spec-03.pdf
http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-redefi-bin-math-04.pdf

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 May 2003 14:27:18 -0400

> in the IANA allocations policy for IPCP code points. Today this is "first

Bernard is right, unfortunately.

IMO, a document for PPP IANA Considerations is needed. At a minimum,
an IANA considerations document would define when and under what
conditions IANA should allocate code points. Right now, there are some
nume spaces where anyone can get a code point just by asking. It would
be quite reasonable for the WG to say "for standards track only" for
some of the number spaces, for example. For a recent example of how to
do this, see draft-aboba-radius-iana-07.txt, which the IESG approved
recently.

If you want to reign in bad uses of PPP, there are ways of documenting
that too, but it's a bit more work. One  possible example is:

     RFC 3427 "Change Process for the Session Initiation Protocol (SIP)"

That document contains the steps that must be followed for extending
SIP. Having such documents makes it a lot easier for the IESG to say
"no" to bad requests, since we would be speaking for the PPP
community.

Thomas

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 14 May 2003 12:35:55 -0600 (MDT)

> From: Thomas Narten <[email-masked]>

> Bernard is right, unfortunately.

Ouch!

> do this, see draft-aboba-radius-iana-07.txt, which the IESG approved

Could we do this for all of the PPP state machines with a single
document?  This seems like a worthwhile effort that should be done
immediately.

> "no" to bad requests, since we would be speaking for the PPP

There are a lot of words in RFC 3427.  Some, such as those about X-headers
don't seem relevant.

Perhaps it would be sufficent to corral all of the PPP (sub)option numbers.

What do we need to do to get at least that started?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 May 2003 11:22:07 -0700 (PDT)

> document?  This seems like a worthwhile effort that should be done

Sure. Just write a document called "IANA Consideration for PPP", and
describe the procedures for assignment of each of the parameters.

It's not all that hard -- you can look at draft-aboba-radius-iana-07.txt
as an example.  In that document we took some of the first come first
served parameters that had been abused and made allocation require review.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 May 2003 15:26:03 -0400

> document?  This seems like a worthwhile effort that should be done

I agree. This gets the biggest bang for the buck.

> There are a lot of words in RFC 3427.  Some, such as those about X-headers

yep. Maybe enough ground can be covered in an IANA considerations
document. For example, when describing the IPCP name space, one could
say it is intended for link-specific PPP-specific configuration
information and is not intended to be used for carrying generic stuff
that can be carried by more general protocols like DHCP or RIP/OSPF.

> What do we need to do to get at least that started?

Go to the IANA web page for PPP and look at all the name spaces. Start
with a document modeled after draft-aboba-radius-iana-07.txt and have
a section or sub-section for each name space and say what the policy
should be for each of them and under what conditions an allocation is
appropriate (Reading RFC 2434 is probably also a good thing at this
point). The key thing it to ensure that sufficient review takes place
by someone familiar with PPP before an assignment is allowed that
might lead to "abuse" of PPP.

Thomas