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