RFC relevance of february

As per Relevance of the word february, we have this rfc below:

Network Working Group L.
Request for Comments: 2516 K.
Category: Informational J.
UUNET Technologies, Inc
D.
D.
RedBack Networks, Inc
R.
RouterWare, Inc
February 1999

A Method for Transmitting PPP Over Ethernet (PPPoE

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

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

The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links

This document describes how to build PPP sessions and encapsulate
packets over Ethernet

This specification is intended to provide the facilities which
defined for PPP, such as the Link Control Protocol, Network-
Control Protocols, authentication, and more. These
require a point-to-point relationship between the peers, and are
designed for the multi-point relationships which are available
Ethernet and other multi-access environments

This specification can be used by multiple hosts on a shared
Ethernet to open PPP sessions to multiple destinations via one
more bridging modems. It is intended to be used with
remote access technologies that provide a bridged Ethernet topology
when access providers wish to maintain the session
associated with PPP

Mamakos, et. al. Informational [Page 1]

RFC 2516 Transmitting PPP Over Ethernet February 1999

This document describes the PPP Over Ethernet encapsulation that
being deployed by RedBack Networks, RouterWare, UUNET and others

1.

Modern access technologies are faced with several conflicting goals
It is desirable to connect multiple hosts at a remote site
the same customer premise access device. It is also a goal
provide access control and billing functionality in a manner
to dial-up services using PPP. In many access technologies, the
cost effective method to attach multiple hosts to the
premise access device, is via Ethernet. In addition, it is
to keep the cost of this device as low as possible while
little or no configuration

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

To provide a point-to-point connection over Ethernet, each
session must learn the Ethernet address of the remote peer, as
as establish a unique session identifier. PPPoE includes a
protocol that provides this

2.

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

3. Protocol

PPPoE has two distinct stages. There is a Discovery stage and a
Session stage. When a Host wishes to initiate a PPPoE session,
must first perform Discovery to identify the Ethernet MAC address
the peer and establish a PPPoE SESSION_ID. While PPP defines
peer-to-peer relationship, Discovery is inherently a client-
relationship. In the Discovery process, a Host (the client
discovers an Access Concentrator (the server). Based on the
topology, there may be more than one Access Concentrator that
Host can communicate with. The Discovery stage allows the Host
discover all Access Concentrators and then select one.
Discovery completes successfully, both the Host and the
Access Concentrator have the information they will use to build
point-to-point connection over Ethernet

Mamakos, et. al. Informational [Page 2]

RFC 2516 Transmitting PPP Over Ethernet February 1999

The Discovery stage remains stateless until a PPP session
established. Once a PPP session is established, both the Host
the Access Concentrator MUST allocate the resources for a PPP
interface

4.

The following packet formats are defined here. The payload
will be defined in the Discovery and PPP sections

An Ethernet frame is as follows

1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The DESTINATION_ADDR field contains either a unicast
destination address, or the Ethernet broadcast address (0xffffffff).
For Discovery packets, the value is either a unicast or
address as defined in the Discovery section. For PPP
traffic, this field MUST contain the peer's unicast address
determined from the Discovery stage

The SOURCE_ADDR field MUST contains the Ethernet MAC address of
source device

The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864
(PPP Session Stage).

Mamakos, et. al. Informational [Page 3]

RFC 2516 Transmitting PPP Over Ethernet February 1999

The Ethernet payload for PPPoE is as follows

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The VER field is four bits and MUST be set to 0x1 for this version
the PPPoE specification

The TYPE field is four bits and MUST be set to 0x1 for this
of the PPPoE specification

The CODE field is eight bits and is defined below for the
and PPP Session stages

The SESSION_ID field is sixteen bits. It is an unsigned value
network byte order. It's value is defined below for
packets. The value is fixed for a given PPP session and, in fact
defines a PPP session along with the Ethernet SOURCE_ADDR
DESTINATION_ADDR. A value of 0xffff is reserved for future use
MUST NOT be

The LENGTH field is sixteen bits. The value, in network byte order
indicates the length of the PPPoE payload. It does not include
length of the Ethernet or PPPoE headers

5. Discovery

There are four steps to the Discovery stage. When it completes,
peers know the PPPoE SESSION_ID and the peer's Ethernet address
which together define the PPPoE session uniquely. The steps
of the Host broadcasting an Initiation packet, one or more
Concentrators sending Offer packets, the Host sending a
Session Request packet and the selected Access Concentrator sending
Confirmation packet. When the Host receives the Confirmation packet
it may proceed to the PPP Session Stage. When the
Concentrator sends the Confirmation packet, it may proceed to the
Session Stage

All Discovery Ethernet frames have the ETHER_TYPE field set to
value 0x8863.

Mamakos, et. al. Informational [Page 4]

RFC 2516 Transmitting PPP Over Ethernet February 1999

The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type
length-value) construct and is defined as follows

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TAG_TYPE is a sixteen bit field in network byte order. Appendix
contains a list of all TAG_TYPEs and their TAG_VALUEs

TAG_LENGTH is a sixteen bit field. It is an unsigned number
network byte order, indicating the length in octets of the TAG_VALUE

If a discovery packet is received with a TAG of unknown TAG_TYPE,
TAG MUST be ignored unless otherwise specified in this document
This provides for backwards compatibility if/when new TAGs are added
If new mandatory TAGs are added, the version number will
incremented

Some example Discovery packets are shown in Appendix B

5.1 The PPPoE Active Discovery Initiation (PADI)

The Host sends the PADI packet with the DESTINATION_ADDR set to
broadcast address. The CODE field is set to 0x09 and the SESSION_
MUST be set to 0x0000.

The PADI packet MUST contain exactly one TAG of TAG_TYPE Service
Name, indicating the service the Host is requesting, and any
of other TAG types. An entire PADI packet (including the
header) MUST NOT exceed 1484 octets so as to leave sufficient
for a relay agent to add a Relay-Session-Id TAG

5.2 The PPPoE Active Discovery Offer (PADO)

When the Access Concentrator receives a PADI that it can serve,
replies by sending a PADO packet. The DESTINATION_ADDR is
unicast address of the Host that sent the PADI. The CODE field
set to 0x07 and the SESSION_ID MUST be set to 0x0000.

Mamakos, et. al. Informational [Page 5]

RFC 2516 Transmitting PPP Over Ethernet February 1999

The PADO packet MUST contain one AC-Name TAG containing the
Concentrator's name, a Service-Name TAG identical to the one in
PADI, and any number of other Service-Name TAGs indicating
services that the Access Concentrator offers. If the
Concentrator can not serve the PADI it MUST NOT respond with a PADO

5.3 The PPPoE Active Discovery Request (PADR)

Since the PADI was broadcast, the Host may receive more than
PADO. The Host looks through the PADO packets it receives
chooses one. The choice can be based on the AC-Name or the
offered. The Host then sends one PADR packet to the
Concentrator that it has chosen. The DESTINATION_ADDR field is
to the unicast Ethernet address of the Access Concentrator that
the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST
set to 0x0000.

The PADR packet MUST contain exactly one TAG of TAG_TYPE Service
Name, indicating the service the Host is requesting, and any
of other TAG types

5.4 The PPPoE Active Discovery Session-confirmation (PADS)

When the Access Concentrator receives a PADR packet, it prepares
begin a PPP session. It generates a unique SESSION_ID for the
session and replies to the Host with a PADS packet.
DESTINATION_ADDR field is the unicast Ethernet address of the
that sent the PADR. The CODE field is set to 0x65 and the SESSION_
MUST be set to the unique value generated for this PPPoE session

The PADS packet contains exactly one TAG of TAG_TYPE Service-Name
indicating the service under which Access Concentrator has
the PPPoE session, and any number of other TAG types

If the Access Concentrator does not like the Service-Name in
PADR, then it MUST reply with a PADS containing a TAG of TAG_
Service-Name-Error (and any number of other TAG types). In this
the SESSION_ID MUST be set to 0x0000.

5.5 The PPPoE Active Discovery Terminate (PADT)

This packet may be sent anytime after a session is established
indicate that a PPPoE session has been terminated. It may be sent
either the Host or the Access Concentrator. The DESTINATION_
field is a unicast Ethernet address, the CODE field is set to 0xa
and the SESSION_ID MUST be set to indicate which session is to
terminated. No TAGs are required

Mamakos, et. al. Informational [Page 6]

RFC 2516 Transmitting PPP Over Ethernet February 1999

When a PADT is received, no further PPP traffic is allowed to be
using that session. Even normal PPP termination packets MUST NOT
sent after sending or receiving a PADT. A PPP peer SHOULD use
PPP protocol itself to bring down a PPPoE session, but the PADT
be used when PPP can not be used

6. PPP Session

Once the PPPoE session begins, PPP data is sent as in any other
encapsulation. All Ethernet packets are unicast. The ETHER_
field is set to 0x8864. The PPPoE CODE MUST be set to 0x00.
SESSION_ID MUST NOT change for that PPPoE session and MUST be
value assigned in the Discovery stage. The PPPoE payload contains
PPP frame. The frame begins with the PPP Protocol-ID

An example packet is shown in Appendix B

7. LCP

The Magic Number LCP configuration option is RECOMMENDED, and
Protocol Field Compression (PFC) option is NOT RECOMMENDED.
implementation MUST NOT request any of the following options,
MUST reject a request for such an option

Field Check Sequence (FCS) Alternatives

Address-and-Control-Field-Compression (ACFC),

Asynchronous-Control-Character-Map (ACCM

The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to
larger size than 1492. Since Ethernet has a maximum payload size
1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID
2 octets, the PPP MTU MUST NOT be greater than 1492.

It is RECOMMENDED that the Access Concentrator ocassionally
Echo-Request packets to the Host to determine the state of
session. Otherwise, if the Host terminates a session without
a Terminate-Request packet, the Access Concentrator will not be
to determine that the session has gone away

When LCP terminates, the Host and Access concentrator MUST stop
that PPPoE session. If the Host wishes to start another PPP session
it MUST return to the PPPoE Discovery stage

Mamakos, et. al. Informational [Page 7]

RFC 2516 Transmitting PPP Over Ethernet February 1999

8. Other

When a host does not receive a PADO packet within a specified
of time, it SHOULD resend it's PADI packet and double the
period. This is repeated as many times as desired. If the Host
waiting to receive a PADS packet, a similar timeout mechanism
be used, with the Host re-sending the PADR. After a specified
of retries, the Host SHOULD then resend a PADI packet

The ETHER_TYPEs used in this document (0x8863 and 0x8864) have
assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use
these values and the PPPoE VER (version) field uniquely identify
protocol

UTF-8 [5] is used throughout this document instead of ASCII. UTF-8
supports the entire ASCII character set while allowing
international character sets as well. See [5] for more details

9. Security

To help protect against Denial of Service (DOS) attacks, the
Concentrator can employ the AC-Cookie TAG. The Access
SHOULD be able to uniquely regenerate the TAG_VALUE based on the
SOURCE_ADDR. Using this, the Access Concentrator can ensure that
PADI SOURCE_ADDR is indeed reachable and can then limit
sessions for that address. What algorithm to use is not defined
left as an implementation detail. An example is HMAC [3] over
Host MAC address using a key known only to the Access > Concentrator
While the AC-Cookie is useful against some DOS attacks, it can
protect against all DOS attacks and an Access Concentrator MAY
other means to protect resources

While the AC-Cookie is useful against some DOS attacks, it can
protect against all DOS attacks and an Access Concentrator MAY
other means to protect resources

Many Access Concentrators will not wish to offer
regarding what services they offer to an unauthenticated entity.
that case the Access Concentrator should employ one of two policies
It SHOULD never refuse a request based on the Service-Name TAG,
always return the TAG_VALUE that was sent to it. Or it SHOULD
accept requests with a Service-Name TAG with a zero TAG_
(indicating any service). The former solution is RECOMMENDED

10.

This document is based on concepts discussed in several forums
including the ADSL forum

Mamakos, et. al. Informational [Page 8]

RFC 2516 Transmitting PPP Over Ethernet February 1999

Copious amounts of text have been stolen from RFC 1661, RFC 1662
RFC 2364.

11.

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

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

[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
for Message Authentication", RFC 2104, February 1998.

[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.

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

Mamakos, et. al. Informational [Page 9]

RFC 2516 Transmitting PPP Over Ethernet February 1999

Appendix

TAG_TYPES and TAG_

0x0000 End-Of-

This TAG indicates that there are no further TAGs in the list.
TAG_LENGTH of this TAG MUST always be zero. Use of this TAG
not required, but remains for backwards compatibility

0x0101 Service-

This TAG indicates that a service name follows. The TAG_VALUE
an UTF-8 string that is NOT NULL terminated. When the TAG_
is zero this TAG is used to indicate that any service
acceptable. Examples of the use of the Service-Name TAG are
indicate an ISP name or a class or quality of service

0x0102 AC-

This TAG indicates that a string follows which uniquely
this particular Access Concentrator unit from all others. It
be a combination of trademark, model, and serial id information
or simply an UTF-8 rendition of the MAC address of the box. It
not NULL terminated

0x0103 Host-

This TAG is used by a Host to uniquely associate an
Concentrator response (PADO or PADS) to a particular Host
(PADI or PADR). The TAG_VALUE is binary data of any value
length that the Host chooses. It is not interpreted by the
Concentrator. The Host MAY include a Host-Uniq TAG in a PADI
PADR. If the Access Concentrator receives this TAG, it
include the TAG unmodified in the associated PADO or
response

0x0104 AC-

This TAG is used by the Access Concentrator to aid in
against denial of service attacks (see the Security
section for an explanation of how this works). The
Concentrator MAY include this TAG in a PADO packet. If a
receives this TAG, it MUST return the TAG unmodified in
following PADR. The TAG_VALUE is binary data of any value
length and is not interpreted by the Host

Mamakos, et. al. Informational [Page 10]

RFC 2516 Transmitting PPP Over Ethernet February 1999

0x0105 Vendor-

This TAG is used to pass vendor proprietary information.
first four octets of the TAG_VALUE contain the vendor id and
remainder is unspecified. The high-order octet of the vendor
is 0 and the low-order 3 octets are the SMI Network
Private Enterprise Code of the Vendor in network byte order,
defined in the Assigned Numbers RFC [4].

Use of this TAG is NOT RECOMMENDED. To ensure inter-operability
an implementation MAY silently ignore a Vendor-Specific TAG

0x0110 Relay-Session-

This TAG MAY be added to any discovery packet by an
agent that is relaying traffic. The TAG_VALUE is opaque to
the Host and the Access Concentrator. If either the Host
Access Concentrator receives this TAG they MUST include
unmodified in any discovery packet they send as a response.
PADI packets MUST guarantee sufficient room for the addition of
Relay-Session-Id TAG with a TAG_VALUE length of 12 octets

A Relay-Session-Id TAG MUST NOT be added if the discovery
already contains one. In that case the intermediate agent
use the existing Relay-Session-Id TAG. If it can not use
existing TAG or there is insufficient room to add a Relay
Session-Id TAG, then it SHOULD return a Generic-Error TAG to
sender

0x0201 Service-Name-

This TAG (typically with a zero-length data section)
that for one reason or another, the requested Service-Name
could not be honored

If there is data, and the first octet of the data is nonzero,
it MUST be a printable UTF-8 string which explains why the
was denied. This string MAY NOT be NULL terminated

0x0202 AC-System-

This TAG indicates that the Access Concentrator experienced
error in performing the Host request. (For example
resources to create a virtual circuit.) It MAY be included
PADS packets

Mamakos, et. al. Informational [Page 11]

RFC 2516 Transmitting PPP Over Ethernet February 1999

If there is data, and the first octet of the data is nonzero,
it MUST be a printable UTF-8 string which explains the nature
the error. This string MAY NOT be NULL terminated

0x0203 Generic-

This TAG indicates an error. It can be added to PADO, PADR
PADS packets when an unrecoverable error occurs and no other
TAG is appropriate. If there is data then it MUST be an UTF-8
string which explains the nature of the error. This string
NOT be NULL terminated

Mamakos, et. al. Informational [Page 12]

RFC 2516 Transmitting PPP Over Ethernet February 1999

Appendix

The following are some example packets

A PADI 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffffffff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffff | Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mamakos, et. al. Informational [Page 13]

RFC 2516 Transmitting PPP Over Ethernet February 1999

A PADO 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 = 0x07 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x47 | 0x6f | 0x20 | 0x52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x65 | 0x64 | 0x42 | 0x61 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x63 | 0x6b | 0x20 | 0x2d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | 0x65 | 0x73 | 0x68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x73 | 0x68 | 0x65 | 0x73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x68 | 0x6f | 0x6f | 0x74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mamakos, et. al. Informational [Page 14]

RFC 2516 Transmitting PPP Over Ethernet February 1999

A PPP LCP packet: The PPP protocol value is shown (0xc021) but
PPP payload is left to the reader. This is a packet from the Host
the Access Concentrator

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x???? |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authors'

Louis
UUNET Technologies, Inc
3060 Williams
Fairfax, VA 22031-4648
United States of

EMail: louie@uu.

Kurt
UUNET Technologies, Inc
3060 Williams
Fairfax, VA 22031-4648
United States of

EMail: lidl@uu.

Jeff
UUNET Technologies, Inc
3060 Williams
Fairfax, VA 22031-4648
United States of

EMail: jde@uu.

Mamakos, et. al. Informational [Page 15]

RFC 2516 Transmitting PPP Over Ethernet February 1999

David
RedBack Networks, Inc
1389 Moffett Park
Sunnyvale, CA 94089-1134
United States of

EMail: carrel@RedBack.

Dan
RedBack Networks, Inc
1389 Moffett Park
Sunnyvale, CA 94089-1134
United States of

EMail:dan@RedBack.

Ross
RouterWare, Inc
3961 MacArthur Blvd., Suite 212
Newport Beach, CA 92660
United States of

EMail: ross@routerware.

Mamakos, et. al. Informational [Page 16]

RFC 2516 Transmitting PPP Over Ethernet February 1999

Full Copyright

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

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

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

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

Mamakos, et. al. Informational [Page 17]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX