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 February 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 February 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 with out 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 February 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 February 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: dkehn@efficient.com
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]