Multiple Encapsulation Methods

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 EtherType0x8100, 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.tx
t
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
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.