idnits 2.17.1 draft-li-ipv4-over-80211ocb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2017) is 2500 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.11-2012' -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Li 3 Internet-Draft Peloton Technology 4 Intended status: Standards Track G. Salgueiro 5 Expires: November 25, 2017 Cisco Systems, Inc. 6 D. Farinacci 7 lispers.net 8 May 24, 2017 10 Transmission of IPv4 over IEEE 802.11 in OCB mode 11 draft-li-ipv4-over-80211ocb-01 13 Abstract 15 This document describes the transmission of IPv4 packets over IEEE 16 802.11-2012 networks when run Outside the Context of a BSS 17 (802.11-OCB, earlier known as 802.11p). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 25, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Transmission of IPv4 over 802.11-OCB . . . . . . . . . . . . 3 56 3.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 58 3.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 6 59 3.3. MAC Address Resolution . . . . . . . . . . . . . . . . . 6 60 3.4. IPv4 Addressing . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 7 63 4.2. Privacy Considerations . . . . . . . . . . . . . . . . . 7 64 4.3. Certificate Considerations . . . . . . . . . . . . . . . 8 65 4.4. Other Considerations . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. IPv4 Packet in Flight . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 This document describes the transmission of IPv4 and ARP packets over 77 IEEE 802.11-2012 networks when run Outside the Context of a BSS 78 (802.11-OCB, earlier known as 802.11p), as documented in 79 [IEEE802.11-2012]. IPv4 packets are encapsulated in a LLC SNAP layer 80 and then the 802.11 MAC layer before transmission. 82 In the following text we use the term "802.11-OCB" to refer to IEEE 83 802.11-2012 when operated with the "OCBActivated" flag set. Previous 84 versions of other documents also referred to this as 802.11p. 86 802.11-OCB networks are used frequently in vehicular communications 87 and have specific safety related requirements that are not discussed 88 here. Nothing in this document should be construed to contradict, 89 contravene, or otherwise deter compliance with other safety 90 requirements and regulations. Specifically, IPv4 is prohibited on 91 the 802.11-OCB 'Control Channel' (channel 178 at FCC/IEEE, and 180 at 92 ETSI). 94 This document only describes the encapsulation of IPv4 packets. 95 Other issues such as addressing, discovery, channel selection, and 96 transmission timing are out of scope for this document. IPv6 is out 97 of scope for this document. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 LLC: The Logical Link Control layer from IEEE 802. Throughout this 106 document, this also assumes the Subnetwork Access Protocol (SNAP) 107 extension with an EtherType protocol on top of SNAP. 109 OCB: Outside the Context of a Basic Service Set identifier. 111 802.11-OCB: IEEE 802.11-2012 text flagged by "dot11OCBActivated". 112 This means: IEEE 802.11e for quality of service; 802.11j-2004 for 113 half-clocked operations; and 802.11p for operation in the 5.9 GHz 114 band and in mode OCB. 116 3. Transmission of IPv4 over 802.11-OCB 118 IEEE 802.11-OCB specifies that packets should be framed with an LLC 119 header and then one of the various 802.11-OCB headers. This document 120 specifies how IPv4 and ARP are encapsulated over 802.11-OCB. 122 3.1. Frame Format 124 IP packets are transmitted over 802.11-OCB within the standard LLC 125 encapsulation using the EtherType code 0x0800, as specified in 126 [RFC1042] and [RFC0894]. 128 IPv4 packets can be transmitted as "IEEE 802.11 Data" or 129 alternatively as "IEEE 802.11 QoS Data". Thus, formatted frames may 130 appear in either of these formats: 132 IPv4 packet IPv4 packet 133 Logical-Link Control Logical-Link Control 134 IEEE 802.11 Data IEEE 802.11 QoS Data 136 This format is slightly different than standard Ethernet framing for 137 IPv4, so implementations SHOULD provide an adaptation layer so that 138 the network layer perceives traditional Ethernet encapsulation. 140 When transmitting an IPv4 packet, the value of the field "Type/ 141 Subtype" in the 802.11 Data header is 0x20 (Data, Data). The value 142 of the field "Type/Subtype" in the 802.11 QoS header is 0x28 (Data, 143 QoS data). The 802.11 data header is 145 0 1 2 3 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Frame Control | Duration | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Receiver Address... 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 ... Receiver Address | Transmitter Address... 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 ... Transmitter Address | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | BSS Id... 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 ... BSS Id | Frag Number and Seq Number | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Within the two Frame Control octets, the bits are: 163 o 2 bits: Protocol Version 165 o 2 bits: Type 167 o 4 bits: Subtype 169 o 1 bit: To DS 171 o 1 bit: From DS 173 o 1 bit: More Frag 175 o 1 bit: Retry 177 o 1 bit: Power Mgmt 179 o 1 bit: More Data 181 o 1 bit: WEP 183 o 1 bit: Order 185 3.1.1. Ethernet Adaptation Layer 187 In general, an adaptation layer is inserted between a MAC layer and 188 the Networking layer to transform some parameters between the form 189 expected by the IP stack and the form provided by the MAC layer. In 190 this case, the goal is to transform the LLC encapsulation into 191 traditional Ethernet encapsulation. This translated encapsulation is 192 not sent over the 802.11-OCB network, but is instead presented by the 193 device driver to the operating system. This allows 802.11-OCB 194 interfaces to easily take advantage of all of the operating system 195 facilities that exist for Ethernet already. 197 On packet reception, this layer takes the IEEE 802.11 Data Header and 198 the Logical-Link Layer Control Header and produces an Ethernet II 199 Header. At transmission, it performs the reverse operation. 201 +--------------------+-------------+-------------+---------+ 202 | 802.11 Data Header | LLC Header | IPv4 Header | Payload | 203 +--------------------+-------------+-------------+---------+ 204 ^ 205 | 206 802.11-to-Ethernet Adaptation Layer 207 | 208 v 209 +--------------------+-------------+---------+ 210 | Ethernet II Header | IPv4 Header | Payload | 211 +--------------------+-------------+---------+ 213 The Receiver and Transmitter Address fields in the 802.11 Data Header 214 contain the same values as the Destination and the Source Address 215 fields in the Ethernet II Header, respectively. The value of the 216 Type field in the LLC Header is the same as the value of the Type 217 field in the Ethernet II Header. The other fields in the Data and 218 LLC Headers are not used by the IPv4 stack. 220 The result of the adaptation layer transformation is a typical IP 221 over Ethernet frame: 223 0 1 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Destination | 227 +- -+ 228 | Ethernet | 229 +- -+ 230 | Address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Source | 233 +- -+ 234 | Ethernet | 235 +- -+ 236 | Address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0| 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPv4 | 241 +- -+ 242 | header | 243 +- -+ 244 | and | 245 +- -+ 246 / payload ... / 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 3.2. Maximum Transmission Unit (MTU) 251 The MTU for IPv4 packets on 802.11-OCB is 1500 octets. It is the 252 same value as IP packets on Ethernet links, as specified in 253 [RFC0894]. While the physical layer and link layer can support 254 slightly larger packets, a different MTU value would cause frequent 255 fragmentation, which would be suboptimal. [Fragmentation] 257 If a packet is fragmented by the IPv4 network layer before 258 transmission on 802.11-OCB, the field "Sequence number" in the 802.11 259 Data header SHOULD increment for each fragment and the "Fragment 260 number" field SHOULD remain 0. This is recommended because the link 261 layer cannot do IP fragment reassembly or aid the final IPv4 262 recipient in any way. Further, the interaction between the network 263 layer and the data link layer is a significant blurring of the layer 264 boundary. 266 3.3. MAC Address Resolution 268 Address Resolution Protocol (ARP) [RFC0826] is used to determine the 269 MAC address used for an IPv4 address, exactly as is done for Ethernet 270 and Wi-Fi, with EtherType 0x0806. 272 3.4. IPv4 Addressing 274 This document does not make a recommendation on the IPv4 addressing 275 strategy that is used on 802.11-OCB networks. A specific network is 276 free to choose the addressing strategy that best suits its specific 277 application. Known successful IPv4 unicast addressing strategies 278 include, but are not limited to: 280 o Static addressing 282 o DHCP with network assigned addresses [RFC2131] 284 o DHCP with private addressing and NAT [RFC1918] [RFC3022] 286 o Link-local addressing [RFC3927] 288 Multicast addressing for IPv4 is as for Ethernet, as described in 289 [RFC1112]. 291 4. Security Considerations 293 4.1. Design Considerations 295 IEEE 802.11-OCB itself does not provide useful security guarantees. 296 The link layer does not provide any authentication mechanism, leaving 297 hosts just as exposed as they would be at a public Wi-Fi hot spot. 299 This section does not address safety-related applications, which are 300 done on non-IP communications. 302 Because 802.11-OCB is specifically intended for mobile applications, 303 privacy is a significant concern. 802.11-OCB already attempts to 304 assist with privacy by having a station change its MAC address. This 305 raises several issues discussed below. 307 4.2. Privacy Considerations 309 The L2 headers of IEEE 802.11-OCB and L3 headers of IPv4 are not 310 encrypted, and expose the MAC address and IP address of both the the 311 source and destination. Adversaries could monitor the L2 or L3 312 headers, track the addresses, and through that track the position of 313 a vehicles over time. 315 For hosts that have concerns about privacy, the obvious mitigation is 316 to periodically use some form of MAC address randomization. We can 317 assume that there will be "renumbering events" causing MAC addresses 318 to change. A change of MAC address MUST induce a simultaneous change 319 of IPv4 address, to prevent linkage of the old and new MAC addresses 320 through continuous use of the same IP Addresses. 322 Unfortunately, the change of an IP address is very likely to cause 323 disruption at the transport layer, breaking TCP connections at the 324 renumbering event and disrupting any outstanding UDP transactions. 325 For this reason, renumbering events MUST be coordinated between the 326 transport, network, and link layers and MUST only happen when there 327 are no active transport connections. For hosts that require a long- 328 term continuous uptime, this will be problematic and hosts MAY choose 329 to forgo renumbering events and sacrifice privacy. 331 MAC address randomization will not prevent tracking if the address 332 stays constant for long intervals. Suppose for example that a 333 vehicle only renumbers when leaving the owner's garage in the 334 morning. It would be trivial to observe the "number of the day" at 335 the known garage location, and to associate that with the vehicle's 336 identity, thereby enabling tracking throughout the day. If 337 renumbering events are too infrequent, they will not protect privacy, 338 but if they are too frequent they will disrupt service. Careful, 339 detailed communications between an implementations layers will be 340 required to produce an optimal result. 342 Normally, hosts would be able to maintain transport connections 343 across renumbering events by making use of multi-path TCP. [RFC6824] 344 With multi-path TCP, a host can advertise multiple addresses to its 345 correspondents, causing the correspondent to send packets to any of 346 the addresses. If any of the addresses stops working, traffic 347 continues to flow on the working addresses. However, in this 348 situation, advertising multiple addresses would defeat the privacy 349 goals. 351 4.3. Certificate Considerations 353 Because 802.11-OCB provides no link level security, some hosts MAY 354 choose to implement cryptographic techniques to provide data privacy 355 and authentication. The common approach to that today would be 356 through the use of certificates and performing a key-exchange before 357 commencing secure communications. 359 The challenge that this creates is that the key exchange needs to be 360 performed prior to the exchange of other key information. Simply 361 transmitting constant certificates in the clear is not optimal as 362 that would violate the privacy requirements. 364 One approach to simply change certificates. To preserve privacy, a 365 host MUST change its certificate any time it has a renumbering event. 367 Other approaches that allow for the private exchange of certificates 368 are also possible and are an area for future study. 370 4.4. Other Considerations 372 At the IP layer, IPsec can be used to protect unicast communications. 373 If no protection is used by the IP layer, upper layers should be 374 cryptographically protected. 376 5. IANA Considerations 378 This document has no IANA actions. 380 6. Acknowledgments 382 The author would like to thank Alexandre Petrescu, Nabil Benamar, 383 Jerome Haerri, Christian Huitema, Jong-Hyouk Lee, and Thierry Ernst 384 for their work on [I-D.petrescu-ipv6-over-80211p] from which much of 385 this text was taken. 387 7. References 389 7.1. Normative References 391 [IEEE802.11-2012] 392 IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) 393 and Physical Layer (PHY) Specifications", IEEE 394 Standard freely available at 395 http://standards.ieee.org/findstds/ 396 standard/802.11-2012.html retrieved on November 17th, 397 2016, March 2012. 399 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 400 Converting Network Protocol Addresses to 48.bit Ethernet 401 Address for Transmission on Ethernet Hardware", STD 37, 402 RFC 826, DOI 10.17487/RFC0826, November 1982, 403 . 405 [RFC0894] Hornig, C., "A Standard for the Transmission of IP 406 Datagrams over Ethernet Networks", STD 41, RFC 894, 407 DOI 10.17487/RFC0894, April 1984, 408 . 410 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 411 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 412 DOI 10.17487/RFC1042, February 1988, 413 . 415 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 416 RFC 1112, DOI 10.17487/RFC1112, August 1989, 417 . 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 425 Configuration of IPv4 Link-Local Addresses", RFC 3927, 426 DOI 10.17487/RFC3927, May 2005, 427 . 429 7.2. Informative References 431 [Fragmentation] 432 Kent, C. and J. Mogul, "Fragmentation considered harmful", 433 ACM SIGCOMM Computer Communication Review Special twenty- 434 fifth anniversary issue. Highlights from 25 years of the 435 Computer Communication Review, Volume 25, Issue 1, January 436 1995. 438 [I-D.petrescu-ipv6-over-80211p] 439 Petrescu, A., Benamar, N., Haerri, J., Huitema, C., Lee, 440 J., Ernst, T., and T. Li, "Transmission of IPv6 Packets 441 over IEEE 802.11 Outside the Context of a Basic Service 442 Set (OCB)", draft-petrescu-ipv6-over-80211p-06 (work in 443 progress), November 2016. 445 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 446 and E. Lear, "Address Allocation for Private Internets", 447 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 448 . 450 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 451 RFC 2131, DOI 10.17487/RFC2131, March 1997, 452 . 454 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 455 Address Translator (Traditional NAT)", RFC 3022, 456 DOI 10.17487/RFC3022, January 2001, 457 . 459 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 460 "TCP Extensions for Multipath Operation with Multiple 461 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 462 . 464 Appendix A. IPv4 Packet in Flight 466 The following diagram shows an IPv4 packet with the IEEE 802.11 Data 467 Header, Logical Link Control Header, IPv4 Header. 469 Radiotap Header v0 470 0 1 2 3 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |Header Revision| Header Pad | Header length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Present flags | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Timestamp | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Timestamp | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Flags | Data Rate | Channel Frequency | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Channel Type | SSI Signal | Antenna | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Radio Flags | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 IEEE 802.11 Data Header 489 0 1 2 3 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type/Subtype and Frame Ctrl | Duration | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Receiver Address... 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 ... Receiver Address | Destination Address... 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ... Destination Address | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Transmitter Address... 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 ... Transmitter Address | Source Address... 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 ... Source Address | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | BSS Id... 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 ... BSS Id | Frag Number and Seq Number | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Logical-Link Control Header 511 0 1 2 3 512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | DSAP |I| SSAP |C| Control field | Org. code... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 ... Organizational Code | Type | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 IPv4 Header 520 0 1 2 3 521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |Version| IHL |Type of Service| Total Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Identification |Flags| Fragment Offset | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Time to Live | Protocol | Header Checksum | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Source Address | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Destination Address | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Options | Padding | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Authors' Addresses 538 Tony Li 539 Peloton Technology 540 1060 La Avenida St. 541 Mountain View, California 94043 542 United States 544 Phone: +1 650 395 7356 545 Email: tony.li@tony.li 547 Gonzalo Salgueiro 548 Cisco Systems, Inc. 549 7025 Kit Creek Rd. 550 Research Triangle Park, NC 27709 551 USA 553 Phone: +1 919 392 3266 554 Email: gsalguei@cisco.com 555 Dino Farinacci 556 lispers.net 557 San Jose, CA 558 USA 560 Email: farinacci@gmail.com