1. Multiple Encapsulation Methods Draft-iab-link-encaps-05.txt Bernard Aboba IETF 67 San Diego, CA

2. Outline History Questions for 16ng

3. 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

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

5. 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).

6. 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.

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

8. 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?

9. Feedback?

10. Background

11. 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.

12. 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)

13. EtherTypes http://standards.ieee.org/regauth/ethertype/eth.txt EtherTypeProtocol 0x0000 - 0x05DCIEEE 802.3 Length Field 0x0600Xerox NS 0x0800Internet Protocol, Version 4 (IPv4) 0x0806Address Resolution Protocol (ARP) 0x1000Berkeley Trailer Negotiation 0x1001-100FBerkeley Trailer encaps/IP 0x8035Reverse Address Resolution Protocol (RARP) 0x809bAppleTalk (Ethertalk) 0x80f3AppleTalk Address Resolution Protocol (AARP) 0x8100IEEE 802.1Q-tagged frame 0x8137Novell IPX (alt) 0x8138Novell 0x86DDInternet Protocol, Version 6 (IPv6) 0x876B RFC 1144 TCP/IP Compression 0x8847MPLS unicast 0x8848MPLS multicast 0x8863PPPoE Discovery Stage 0x8864PPPoE Session Stage 0x88A2ATA over Ethernet 0xFFFF Reserved http://www.iana.org/assignments/ethernet-numbers

14. 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

15. 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

16. 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.

17. 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.”