RE: Extending IPCP for Route Table Entries

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 <carrel@xxxxxxxxxxx>
   Dan Simone <dan@xxxxxxxxxxx>
   Che-Lin Ho <che@xxxxxxxxxxx>
   Tom Stoner <tstoner@xxxxxxxxxxx>
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA  95134
   United States of America









































Carrel                                                          [Page9]


-----Original Message-----
From: Vernon Schryver
To: ietf-ppp@xxxxxxxxx
Sent: 5/12/03 4:45 PM
Subject: Re: Extending IPCP  for Route Table Entries

> From: Doug Kehn <dkehn@xxxxxxxxxxxxx>

> 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    vjs@xxxxxxxxxxxx