Multiple Encapsulation Methods Draft-iab-link-encaps-05 txt Bernard Aboba IETF

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

Outline • History • Questions for 16 ng

History • Ethernet vs. IEEE 802 Encapsulation – IPv 4 over Ethernet: RFC 894 – IPv 4 over IEEE 802: RFC 1042 • Ethernet Trailer Encapsulation: RFC 893 • PPP – IPCP: RFC 1332, IPv 6 CP: 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, IPv 6 CP) and layer 2 (BCP) encapsulations • In practice, this rarely happens – Hosts rarely implement BCP – Bridges typically do not also negotiate IPCP/IPv 6 CP

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 16 ng • Roaming – What if an MS supporting only Ethernet CS roams to a network supporting only IPv 4 or IPv 6 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 + IPv 4 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. 1 Q adds an additional 4 bytes of header (2 for Ether. Type=0 x 8100, 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 Ether. Type (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)

Ether. Types http: //standards. ieee. org/regauth/ethertype/eth. txt http: //www. iana. org/assignments/ethernet-numbers Ether. Type Protocol 0 x 0000 - 0 x 05 DC IEEE 802. 3 Length Field 0 x 0600 Xerox NS 0 x 0800 Internet Protocol, Version 4 (IPv 4) 0 x 0806 Address Resolution Protocol (ARP) 0 x 1000 Berkeley Trailer Negotiation 0 x 1001 -100 F Berkeley Trailer encaps/IP 0 x 8035 Reverse Address Resolution Protocol (RARP) 0 x 809 b Apple. Talk (Ethertalk) 0 x 80 f 3 Apple. Talk Address Resolution Protocol (AARP) 0 x 8100 IEEE 802. 1 Q-tagged frame 0 x 8137 Novell IPX (alt) 0 x 8138 Novell 0 x 86 DD Internet Protocol, Version 6 (IPv 6) 0 x 876 B RFC 1144 TCP/IP Compression 0 x 8847 MPLS unicast 0 x 8848 MPLS multicast 0 x 8863 PPPo. E Discovery Stage 0 x 8864 PPPo. E Session Stage 0 x 88 A 2 ATA over Ethernet 0 x. FFFF 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 Ether. Type [RFC 893]. – Type is calculated as 0 x 1000 plus the number of 512 -byte pages of data (maximum of 16 pages or 8192 bytes) • Packet formulation – L 2 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. ”