Multiple Encapsulation
Methods
Draft-iab-link-encaps-05.txt
Bernard Aboba
IETF 67
San Diego, CA
Outline
• History
• Questions for 16ng
History
• Ethernet vs. IEEE 802 Encapsulation
– IPv4 over Ethernet: RFC 894
– IPv4 over IEEE 802: RFC 1042
• Ethernet Trailer Encapsulation: RFC 893
• PPP
– IPCP: RFC 1332, IPv6CP: RFC 2472
– Bridging Control Protocol: RFC 3518
• ATM
– MPOA: RFC 1483
– Classical IP over ATM: RFC 1577
PPP
• Possible to negotiate both layer 3 (IPCP,
IPv6CP) and layer 2 (BCP) encapsulations
• In practice, this rarely happens
– Hosts rarely implement BCP
– Bridges typically do not also negotiate
IPCP/IPv6CP
Implications of Mixed Environments
(From RFC 1042)
• A host can potentially receive both Ethernet and IEEE
802.3 frames
– If it does, it must keep track of which link protocol was used with
each host and send using the right encapsulation.
• Link layer broadcasts will not reach all hosts, just those
who can receive the encapsulation used in the
broadcast.
• To enable hosts reading and sending only one
encapsulation to communicate with each other, an IP
gateway is recommended.
• The MTU of Ethernet (1500) is different from the IEEE
802.3 MTU (1492).
Recommendations from RFC 1122
• It is not useful or even possible for a dual-format
host to discover automatically which format to
send, because of the link-layer broadcast issue.
• Every host:
– MUST be able to send and receive using RFC 894
encapsulation (Ethernet)
– SHOULD be able to receive RFC 1042 (IEEE 802)
packets intermixed with RFC 894 packets
– MAY be able to send packets using RFC 1042
encapsulation
• A host that implements sending both RFC 894
and 1042 encapsulation MUST provide a
configuration switch to select which is sent, and
this switch MUST default to RFC 894.
What We Learn From History
• Multiple encapsulations should be avoided wherever
possible
– After effects of DIX vs. IEEE 802 are still with us today
– Mitigating approaches are not completely satisfactory
• Automated discovery of link encapsulation is complex
and inefficient
– Best done at the link layer
– Requires keeping state for each destination (not a shopstopper)
– Results in higher bandwidth overhead and latency plus
implementation complexity
• IP gateways are not a panacea
– IP gateways need to support separate virtual interface for each
encapsulation.
– Separate prefixes needed for each encapsulation so that hosts
can avoid keeping state.
Questions for 16ng
• Roaming
– What if an MS supporting only Ethernet CS
roams to a network supporting only IPv4 or IPv6
CS?
• Interoperability
– What if the Mobile Station (MS) and Base
Station (BS) CS negotiate more than one way to
send a given packet?
• Example: Ethernet CS + IPv4 CS
– What if MS and BS do not have any CSes in
common?
Feedback?
Background
Ethernet Header
• The 7 byte Preamble and 1 byte Start Frame Delimiter are not shown.
• Data field is at least 46 bytes, to bring the minimum frame size to 64
bytes.
• Ethernet Jumbo frames can be as large ~9000 bytes
• 802.1Q adds an additional 4 bytes of header (2 for
EtherType=0x8100, 2 for Tag Control Information).
– With 1500 bytes of data this brings the total frame size to 1522.
IEEE 802 Header
• Data and FCS omitted for brevity
• How is IEEE 802 Length distinguished from Ethernet
Type?
– If the value of the field is less than or equal to 1500, then it
indicates the Length in bytes of the subsequent MAC Client Data
field (IEEE 802 encapsulation)
– If the value of the field is greater than or equal to 1536, then it
indicates the EtherType (Ethernet encapsulation).
• IEEE 802.3 and Ethernet have different MTUs!
– IEEE 802.3 MTU is 1492 (1518 – 18 (MAC header + FCS) – 8 (LLC +
SNAP header), not including IP headers)
EtherTypes
http://standards.ieee.org/regauth/ethertype/eth.txt
http://www.iana.org/assignments/ethernet-numbers
EtherType
Protocol
0x0000 - 0x05DC
IEEE 802.3 Length Field
0x0600
Xerox NS
0x0800
Internet Protocol, Version 4 (IPv4)
0x0806
Address Resolution Protocol (ARP)
0x1000
Berkeley Trailer Negotiation
0x1001-100F
Berkeley Trailer encaps/IP
0x8035
Reverse Address Resolution Protocol (RARP)
0x809b
AppleTalk (Ethertalk)
0x80f3
AppleTalk Address Resolution Protocol (AARP)
0x8100
IEEE 802.1Q-tagged frame
0x8137
Novell IPX (alt)
0x8138
Novell
0x86DD
Internet Protocol, Version 6 (IPv6)
0x876B
RFC 1144 TCP/IP Compression
0x8847
MPLS unicast
0x8848
MPLS multicast
0x8863
PPPoE Discovery Stage
0x8864
PPPoE Session Stage
0x88A2
ATA over Ethernet
0xFFFF
Reserved
Comparison of 1042 & 1122
• Send & Receiving
– 1024: It is assumed that most computers will read and
send using only one protocol
– 1122: Sending and receiving RFC 894 a MUST
implement
– 1122: Receiving RFC 1042 a SHOULD implement,
sending a MAY implement
– 1122: RFC 894 a MUST use by default
• Format discovery
– 1024: a host receiving both 894 & 1024 must keep
track and send using the right encapsulation
– 1122: Automatic discovery is not useful or even
possible
• 1122 guarantees that a host can receive RFC 894, so no
need to keep track or send using the right encapsulation
Trailer Encapsulation (RFC 893)
• Enabled to minimize memory-to-memory copy
operations performed by a receiving host
– Done by moving variable length headers (e.g. IP + TCP) after
the data segment
– Enables reception on a page aligned boundary
• Packets using trailers utilize a distinct EtherType
[RFC893].
– Type is calculated as 0x1000 plus the number of 512-byte pages
of data (maximum of 16 pages or 8192 bytes)
• Packet formulation
– L2 header as normal
– Data minus IP and TCP header always a multiple of 512 bytes
– Trailer: Original Type (2) + Header Length (2) + IP and TCP
headers
– Frame Check Sequence
Negotiation
• Potential for four encapsulations!
– IEEE 802 w or w/o trailers
– Ethernet w or w/o trailers
• Trailer negotiation
– ARP exchange completed using the IP protocol type
– Host that wants to speak trailers will send an additional “trailer
ARP reply”
• Receiver can add the host to the list of machines that understand
trailers (e.g. marking the ARP cache entry).
– Receiving host replies to “trailer ARP reply” with a “trailer ARP
reply”
• 4.2 BSD implementation
– Did not implement trailer negotiation
– Configured trailers at boot time, assumed that all hosts either did
or did not implement it.
RFC 1122 on Trailers
• “The trailer protocol for link-layer
encapsulation MAY be used, but only
when it has been verified that both
systems (host or gateway) involved in the
link-layer communication implement
trailers. If the system does not dynamically
negotiate use of the trailer protocol on a
per-destination basis, the default
configuration MUST disable the protocol.”