Internet DRAFT - draft-carrel-info-pppoe-ext
draft-carrel-info-pppoe-ext
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@redback.com>
Dan Simone <dan@redback.com>
Che-Lin Ho <che@redback.com>
Tom Stoner <tstoner@redback.com>
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
United States of America
Carrel [Page9]
