Subject: Extending IPCP for Route Table Entries

From: Doug Kehn <[email-masked]>
Date: Mon, 12 May 2003 16:35:42 -0500

All,

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.

Thanks...
doug

INTERNET-DRAFT                                                 Doug Kehn
draft-kehn-info-ppp-ipcp-ext-00.txt              Efficient Networks Inc.
Category: Informational                                         May 2003
Expires: November 2003

           PPP Internet Protocol Control Protocol Extensions
                                  for
                          Route Table Entries

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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/ieft/1id-abstracts.txt

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

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines a family of Network Control Protocols (NCPs) for establishing
   and configuring different network-layer protocols.  The PPP Internet
   Protocol Control Protocol (IPCP) [2] defines the NCP for establishing
   and configuring the Internet Protocol (IP) [3].

   This document extends IPCP by defining the negotiation of IP route
   table entries.  This extension provides added functionality but is
   optional and preserves compatibility.

1. Introduction

Kehn                          Informational                     [Page 1]

INTERNET DRAFT                                                  May 2003

   PPP is widely used by broadband service providers as the protocol of
   choice for connecting hosts to the Internet.  PPP is popular because
   it is a well-known protocol that has been utilized by dial-up service
   providers for many years.  PPP also provides per-user access control,
   billing, etc.  These later features of PPP are the most appealing to
   providers.  In recent years, PPP has seen two transport extensions
   emerge to support broadband access.  These transports are PPP over
   Ethernet (PPPoE) [5] and PPP over AAL5 (PPPoA) [6].  With the
   emergence of broadband, the PPP client is migrating from the
   subscribers PC to the broadband customer premise equipment (CPE).

   Broadband provides more bandwidth to the subscriber.  Broadband
   service providers are wanting to utilize this additional bandwidth to
   provide additional services to subscribers.  Service Providers, for
   obvious reasons, desire to isolate these additional services from
   standard Internet service.  As stated earlier, PPP provides the per-
   user access control, billing, etc.  This makes PPP a logical choice
   for providing these additional services.  PPP also allows the service
   provider to utilize its investment in networking hardware used to
   provide standard Internet access.

   If PPP is to be used for both Internet access and additional service
   access, PPP hosts (whether residing in the PC or CPE) must be able to
   establish multiple PPP links.  The presence of multiple PPP links can
   complicate packet routing decisions in the host.  This document
   proposes an extension to IPCP to address the packet routing issues
   induced in the presence of multiple PPP links.  The extension
   provides the ability to add route table entries for specific PPP
   interfaces.

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 [4].

3. Additional IPCP Configuration Option

3.1 Route-Add

   Description

      This configuration option defines a method for negotiating zero or
      more route table entries for the PPP interface on the local
      (client) end of the link.  If the local peer supports the Route-
      Add option, it MUST include the Route-Add option with a length of
      2 to its IPCP Configure Request.  The remote (server) peer, if it
      supports the Route-Add option, SHOULD return the appropriate

Kehn                          Informational                     [Page 2]

INTERNET DRAFT                                                  May 2003

      number of Route-Add option entries in its IPCP response.  If the
      remote peer does not wish to add any route entries to the local
      peer, the remote peer MUST NOT include the Route-Add option in its
      response.  The local peer MUST accept this response as an
      indication that the remote peer does not wish to add any routes to
      the interface.

      If the remote peer does not support the Route-Add option (e.g.
      current implementations), the remote peer MAY reject the Route-Add
      option.  This is an indication to the local peer that the remote
      peer does not support the Route-Add option and IPCP negotiation
      MUST continue without it.

      A Route-Add option entry with a Route-Address and Route-Mask of
      zero indicates a default route.

      Any routes added via the Route-Add option MUST be deleted when the
      IPCP layer terminates.

   A summary of the Route-Add option format is shown below.  The fields
   are transmitted from left to right and are in network-byte order.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Route-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Address (cont)      |        Route-Mask
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Mask (cont)         |        Route-Next-Hop
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Next-Hop (cont)     |        Route-Metric
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Metric (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      (To be assigned by IANA)

   Length

      18+

   Route-Address

      The four octet field defining the destination network or host
      address.

Kehn                          Informational                     [Page 3]

INTERNET DRAFT                                                  May 2003

   Route-Mask

      The four octet field defining the subnet mask for the route.  For
      host route entries, this field MUST be set to all one's.

   Route-Next-Hop

      The four octet field defining the route's next hop.  This field
      MAY be zero if the next hop for the route is the remote peer.

   Route-Metric

      The four octet field defining the metric value for the route.

Normative References

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

   [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit,
   May 1992.

Informative References

   [3] Postel, J., "Internet Protocol", RFC 971, USC/Information
   Sciences Institute, September 1981.

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

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

   [6] Gross, et. al., "PPP Over AAL5", RFC 2364, July 1998.

Security Considerations

   Security issues are not discussed in this memo.

IANA Considerations

   Requires IPCP option number assignment for the Route-Add option.

Acknowledgments

   This draft was inspired by the "work in progress" <draft-carrel-info-
   pppoe-ext-00.txt>.

Kehn                          Informational                     [Page 4]

INTERNET DRAFT                                                  May 2003

   Special thanks goes to Stephen Lyda (Efficient Networks, Inc.), and
   Dan Dworin (Efficient Networks, Inc.) for their feedback.

Author's Address

   Doug Kehn
   Efficient Networks Inc.
   4849 Alpha Road
   Dallas, TX  75244
   USA

   Phone: +1 972 852 1000
   EMail: [email-masked]

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Kehn                          Informational                     [Page 5]

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 12 May 2003 15:45:23 -0600 (MDT)

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

> 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]