idnits 2.17.00 (12 Aug 2021) /tmp/idnits31372/draft-bormann-rohc-over-802-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC3095]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 4688 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) == Unused Reference: 'RFC3242' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC3408' is defined on line 586, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4995 (Obsoleted by RFC 5795) -- Obsolete informational reference (is this intentional?): RFC 3242 (Obsoleted by RFC 4362) -- Obsolete informational reference (is this intentional?): RFC 4996 (Obsoleted by RFC 6846) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track July 13, 2009 5 Expires: January 14, 2010 7 Robust Header Compression (ROHC) over 802 networks 8 draft-bormann-rohc-over-802-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 14, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Various proposals have been submitted to the ROHC working group for 47 enabling the use of ROHC [RFC3095] header compression over Ethernet, 48 802.11 and other 802-based links. 50 Previous proposals generally suffered from a lack of systems 51 perspective on 802 networks. The present document attempts to supply 52 some systems perspective and provides a rough outline for a solution. 54 This is a submission to the IETF ROHC WG. Please direct discussion 55 to its mailing list, rohc@ietf.org 57 $Revision: 1.9 $ 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Overall Requirements . . . . . . . . . . . . . . . . . . . 3 64 2.2. Elements of a Solution . . . . . . . . . . . . . . . . . . 4 65 2.3. Who Should Standardize? . . . . . . . . . . . . . . . . . 5 66 2.4. Why not just use PPPoE? . . . . . . . . . . . . . . . . . 6 67 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Ethernet Minimum Frame Size . . . . . . . . . . . . . . . 6 69 3.2. Negotiation and the existing IP-over-802 model . . . . . . 7 70 4. Non-Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Padding a non-issue? . . . . . . . . . . . . . . . . . . . 8 73 5. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. ULE encapsulation . . . . . . . . . . . . . . . . . . . . 10 75 6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 RFC 3095 [RFC3095] defines four ROHC profiles for the header 86 compression of IP, UDP, RTP, ESP, and related protocol headers, as 87 well as a framework that has been used to define a number of related 88 profiles (such as IP ROHC [RFC3843] and UDP-lite based RTP ROHC 89 [RFC4019]). Since, the framework has been extracted into RFC 4995 90 [RFC4995] and several "version 2" ROHC profiles have been defined 91 [RFC4996] [RFC5225]. ROHC as a framework is also useful for 92 transporting legacy compression formats where this is desirable 93 [I-D.bormann-rohc-avt-crtp-profile]. 95 To enable robust header compression over a specific link layer, the 96 ROHC profile specifications have to be complemented by a link-layer 97 specific specification, typically called "ROHC-over-X". One such 98 specification has been defined in the IETF, ROHC over PPP [RFC3241]. 99 Other ROHC-over-X specifications have been defined by the 100 organizations defining specific link layers, such as 3GPP. 102 No specification currently exists for applying robust header 103 compression to IEEE 802 networks such as Ethernet, 802.11, or 802.16. 104 A number of proposals have been made to the IETF ROHC WG , but it 105 became obvious quickly that the solutions that seem to suggest 106 themselves do not work at the desirable level of efficiency. 108 The lack of a specification for IEEE 802 networks also impacts 109 related IETF standards, such as IP over DVB [RFC4326]. While IP over 110 DVB is not by itself an IEEE 802 network, actual implementations 111 often are closely tied to Ethernets by technologies related to 112 bridging, making some form of interoperability at the compressed 113 level desirable. 115 This document first discusses some issues about ROHC-over-802, then 116 lists some potential non-issues, defines an encapsulation format for 117 ROHC-over-802, and finally discusses an appropriate negotiation 118 mechanism. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Discussion 126 2.1. Overall Requirements 128 There is little need for robust header compression in a classical 129 Ethernet (802.3) environment, which is both relatively high-speed and 130 (at least at the segment level) virtually error-free. However, WLAN 131 (802.11) and WPAN (802.15) links are often bandwidth limited; the 132 same will hold for WMAN (802.16) links. They also (depending on link 133 quality and load) can exhibit loss and delay patterns that would 134 motivate the use of ROHC in such scenarios. Since voice over IP is 135 and will be commonly used in these networks, header compression will 136 continue to be useful. 138 In the ROHC framework, header compression is performed at the 139 boundary between Layer 3 (IP) and Layer 2 (802, in the case of ROHC- 140 over-802). 802 networks are often bridged, i.e. multiple 802 141 technologies may contribute to a Layer 2 path that constitutes what 142 is considered to be "the link" from a ROHC framework point of view. 143 In practical implementation, nodes such as routers (often one end of 144 a ROHC channel) in many cases don't connect directly to 802.11 links, 145 but send packets on 802.3 (Ethernet) links that then are bridged by 146 "Access Points" to 802.11 links. System architectures for other 802 147 technologies also often make use of bridging. 149 (In this document, we use the term "bridging" for any kind of 150 interconnection of IEEE 802 LANs above the physical layer but below 151 the MAC service boundary, i.e. whenever an L3-visible hop is built 152 from multiple L2 constituents by interconnection with bridge-like 153 devices -- even if not all these L2 intermediate systems are 154 completely compliant to the definitions of the term "bridge" in 155 section 6.3.2 of IEEE 802 and in IEEE 802.1D.) 157 One can conclude: It is not sufficient to just look at the wireless 158 links -- ROHC-over-802 also needs to work on 802.3 (and other fixed- 159 line 802) networks. In effect, a single solution for applying ROHC 160 to all 802 (and related) environments needs to be defined independent 161 of the physical layer technology. By staying above the MAC service 162 interface, the solution can be largely oblivious of the specifics of 163 the 802 technologies employed. A nice side effect is that this will 164 simplify both standardization and implementation. 166 2.2. Elements of a Solution 168 A ROHC-over-X specification needs to define two elements: 169 o An encapsulation for ROHC framework packets, and 170 o a negotiation mechanism for agreeing on the use of ROHC and on the 171 parameters of the ROHC channel. 173 (While a negotiation mechanism is not strictly needed for every ROHC- 174 over-X document, it is clearly too late for the alternative, i.e. 175 making ROHC mandatory and defining fixed channel parameter values for 176 any use of IP over 802.) 178 2.3. Who Should Standardize? 180 (This section is not intended to become part of any standards 181 document resulting from this work.) 183 In previous discussions, the question was raised which body should 184 standardize ROHC-over-802. As mentioned in the introduction, one 185 ROHC-over-X protocol has been defined in the IETF, other ones have 186 been defined in the standards bodies defining the link layers under 187 consideration. 189 In the view of the author, a good test would be to see who has 190 defined the IP-over-X specification. The ROHC-over-PPP specification 191 clearly fits in the IETF as both the IP-over-PPP specification and 192 the PPP specification itself are IETF specifications. For 802 193 networks, the IETF also has specified the link layer mapping of IP, 194 including a number of ancillary protocols (ARP and ND) necessary for 195 these mappings. If these protocols need to be extended, it would be 196 more appropriate for the IETF to do so. The system issues of complex 197 802 networks do have a bearing on ROHC-over-802 and are in the domain 198 of the IEEE; on the other hand, no good arguments exist currently 199 that would call for an extension to the 802 protocols for ROHC. In 200 summary, the author believes that IETF is the right body to work on 201 ROHC-over-802. 203 Related questions are: a) Who is the community of interest? Which 204 standards meetings do they attend? b) Which body has the required 205 expertise? c) What existing work is underway? Are there conflicts 206 between that work and the proposed work? 208 For question a) the answer appears to be the group of people who 209 participate within the IETF ROHC WG. This group also has 210 demonstrated expertise in header compression issues, but not 211 necessarily in the details of link layer capabilities negotiation 212 that may need to be part of a solution. 214 (If work is required on the subject of link layer capabilities 215 negotiation, e.g. use of ROHC, this would fit within the charter of 216 existing IEEE 802 groups; however, staying above the MAC service 217 interface would avoid the architectural need for this. Otherwise, 218 while the ROHC over 802 component seems best suited to IETF, there 219 may be link layer components to the work that are best done in IEEE 220 802.) 222 In any case, close review of this work by IEEE 802 experts is 223 advisable. 225 2.4. Why not just use PPPoE? 227 An informational RFC specifies a widely deployed specification for 228 PPP over Ethernet (PPPoE [RFC2516]), and, as mentioned there is a 229 specification for ROHC over PPP [RFC3241]. For a number of reasons, 230 just combining these as a ROHC-over-802 solution would be suboptimal: 232 1. PPPoE's encapsulation together with the PPP encapsulation has a 233 fixed overhead of eight bytes per packet, negating some of the 234 savings provided by header compression. 235 2. PPPoE does not solve the minimum-size padding problem (see 236 below). 237 3. PPPoE has a different model than the usual IP-over-802 model, 238 with discovery and session stages, and possibly multiple PPP 239 sessions. This complexity is often not required. 241 On the other hand, if PPPoE is in active use on an 802 link, adding 242 ROHC-over-PPP may be a simple way to add robust header compression. 244 3. Issues 246 3.1. Ethernet Minimum Frame Size 248 Due to its roots in the CSMA/CD protocol, Ethernet (IEEE 802.3) 249 defines a minimum frame size of 64 bytes. Of these, 14 bytes are 250 used for the MAC header and 4 are used for the MAC trailer (frame 251 check sequence), which means that the minimum payload of an Ethernet 252 packet is 46 bytes. 254 The existing IPv4-over-802 [RFC1042] specification uses the "total 255 size" field in the IP packet to indicate how much of the 802 packet 256 payload is actually an IP packet; this indirectly indicates the 257 presence of padding, if any. 259 ROHC compresses away the "total size" field. Instead, it relies on 260 the link layer (or the ROHC-over-X protocol) to provide a packet 261 size. A ROHC-over-802 encapsulation could use a number of ways to 262 provide this packet size: 264 1. It still could rely on the link layer size and use ROHC padding 265 schemes to always inflate the size to at least 46 bytes. 266 2. It could add a length field. 267 3. It could make use of the length-field variant of the 802 MAC 268 header format; this requires a different way of demultiplexing 269 ROHC packets from other LLC packets. 271 Note that solutions 1 and 2 mean that ROHC-compressed packets shorter 272 than 46 bytes will be padded out to this length if they ever go over 273 an 802.3 link. Worse, there will be no way for an 802.3-to-802.x 274 bridge to identify this padding and remove it, so the padding will 275 remain on any wireless segments of the link layer path. Given that 276 many voice over IP packets will have payloads of 10 to 20 bytes and 277 headers often can be compressed down to 3 bytes or less, this entails 278 a significant overhead. 280 So, apart from the issue of properly indicating padding, a more 281 interesting property of a ROHC-over-802 encapsulation is whether it 282 allows 802.3-to-802.x bridges to remove any padding inserted on the 283 802.3 segments. 285 3.2. Negotiation and the existing IP-over-802 model 287 In the existing IP-over-802 model (as exemplified by IPv4-over-802 288 [RFC1042]) assumes that once the MAC (link layer) address of a node 289 is known, packets can be sent to it. No channel setup/teardown is 290 provided for. In particular, a node can lose its state (be rebooted) 291 and packets can still be sent to it based on the knowledge of the MAC 292 address. 294 (Note that channel setup/teardown procedures that may be available 295 with specific 802 technologies such as 802.11 are often not end-to- 296 end with respect to the L2 path. E.g., a router connected to an 297 802.3 segment connected to an 802.11 AP may not notice when the 298 802.11 station goes away and comes back.) 300 The ROHC channel model [RFC3759] assumes that channel state is 301 maintained explicitly, at least if the more advanced O- and R-modes 302 are to be used. In addition, this channel setup is used to negotiate 303 parameters of the channel (such as variants of the encapsulation 304 format or the maximum number of compression contexts supported). 306 Also, while there is a ROHC channel for each direction, each ROHC 307 channel itself is bidirectional in the sense that (at least if not 308 just U-mode is to be used) there needs to be a way to return 309 feedback. 311 Finally, only the receiving end of a packet flow may be aware that 312 there is a benefit in using header compression (for illustration, 313 consider a VoWLAN phone that is receiving packets from a router that 314 is different than the router it chose as its default router and thus 315 for the reverse packet flow). Therefore, there should be a way to 316 initiate the setup of a ROHC channel from the receiving end. 318 4. Non-Issues 320 4.1. Reordering 322 Fortunately, 802 links are sequence-preserving, so there is no need 323 to re-sequence packets to avoid reordering (as would be required by 324 unmodified use of the current ROHC framework and profiles). 326 (The sequence preservation property holds as long as all packets of a 327 context are sent on the same 802.1p priority group. The author is 328 unable to imagine good reasons for using multiple 802.1p priority 329 groups for one ROHC context.) 331 (See also ROHC over PPP [RFC3241], section 1, which says:) ROHC 332 assumes that the link layer delivers packets in sequence. PPP 333 normally does not reorder packets. When using reordering mechanisms 334 such as multiclass multilink PPP [RFC2686], care must be taken so 335 that packets that share the same compression context are not 336 reordered. (Note that in certain cases, reordering may be acceptable 337 to ROHC, such as within a sequence of packets that all do not change 338 the decompression context.) 340 4.2. Padding a non-issue? 342 One argument could be that the padding issue outlined in Section 3.1 343 can be ignored for most 802 networks, either because the payloads 344 will be larger than for the most heavily compressing voice codecs or 345 because the header overhead is already rather high (e.g., for 346 802.11b, the link-layer header overhead in typical configurations is 347 about as large as that of three-digit numbers of bytes in the 348 payload). 350 The author takes the viewpoint that a solution that is intended to be 351 used universally through the 802 space does need to address padding. 353 5. Encapsulation 355 Based on the considerations above, this document proposes to use LLC 356 encapsulation of ROHC packets. Several approaches would have been 357 possible: 359 1. An SAP value (Logical Link Control Address) is allocated to ROHC. 360 The per-packet overhead is reduced to three bytes. Note that 361 this means the negotiation protocol needs to fix the small-CID 362 vs. large-CID choice (alternatively, ROHC-over-802 could simply 363 always use large CIDs, or even a pair of SAP values could be 364 allocated). 366 2. SAP 0xAA is used. By setting the first byte of the OUI to a 367 value illegal for an OUI (multicast/private), the rest of the 368 frame can be used for the ROHC packet, reducing the overhead to 369 four bytes. The first (illegal OUI) byte can be used to 370 demultiplex variants, e.g. small-CID and large-CID ROHC packets 371 as well as possible negotiation protocol packets (see below). 372 What would be the second and third OUI bytes are already used for 373 the ROHC packet. 374 3. A full SNAP header is used. (From an overhead perspective, for 375 802.3 networks this is not better than the PPPoE case, but, like 376 the previous proposals, it does allow the removal of padding by 377 bridges.) Note that, to maintain reliable padding removal even 378 over multiple header conversions between 802.3 and other types of 379 802 links, this could NOT be a basic ethertype-carrying SNAP 380 header -- this would be converted to an 802.3 header on the first 381 conversion to 802.3 and would lose its padding-removal property 382 on any further conversions. To prevent this, a non-zero OUI 383 could be used. 385 Of these theoretically possible approaches, this document chooses 386 variant 1. The actual SAP (SSAP/DSAP) value (Logical Link Control 387 Address) to be used is to be defined (preferably one allocated by the 388 registration authority [refauth]); for testing until the SAP value is 389 assigned, the unreserved value of AC (hex) should be used. 391 In summary, the frame format including an Ethernet MAC header could 392 look like in Figure 1 (the CRC in the MAC trailer is not shown). The 393 Ethernet MAC header includes the length field, which is the length of 394 the ROHC header and payload plus the static LLC header. This means 395 the total per-packet overhead is 21 bytes, 18 bytes for the Ethernet 396 MAC header and trailer and three bytes for the LLC header carrying 397 the ROHC identification. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Destination MAC Address | 403 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 406 | Source MAC Address | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | ROHC Length + 3 | ROHC SAP | ROHC SAP | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | 0x03 (UI) | ROHC header and payload... 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 1: ROHC packet including Ethernet MAC header 415 5.1. ULE encapsulation 417 For IP over DVB, bridged frame encapsulation (type 0x0001) can be 418 used unchanged. If a more compact encoding (more like the ethertype 419 compatible formats) is required, the encapsulation as defined in 420 Figure 2 and Figure 3 can be used. (The type value is provisional 421 and needs to be defined in the ULE type registry.) 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |0| Length (15b) | Type = 0x00AC | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Receiver Destination NPA Address (6B) | 429 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 432 | | 433 = ROHC header and payload... = 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | (CRC-32) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Figure 2: ROHC packet in ULE (D=0) 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |1| Length (15b) | Type = 0x00AC | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 = ROHC header and payload... = 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | (CRC-32) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 3: ROHC packet in ULE (D=1) 455 6. Negotiation 457 Negotiation of ROHC channels can either be piggy-backed on the 458 existing address resolution/neighbor discovery protocols or a 459 completely separate negotiation protocol can be used. 461 For IPv4, extending ARP sounds rather difficult at this point in the 462 evolution of this protocol. For IPv6, while ND is probably a more 463 extensible protocol, it is not clear that it is the right place for 464 negotiating link-layer characteristics. 466 Instead, a simple negotiation protocol should be defined that is 467 based on regularly probing the peer node for ROHC capability and 468 offering a capability set. A magic number scheme can be used both to 469 ensure liveness of the peer state assumed and as a basic security 470 measure. 472 The negotiation protocol should preferably share its encapsulation 473 with the ROHC encapsulation itself to ensure probes only arrive if 474 there is no obstacle to LLC-style frames. Additional checking could 475 be made part of the protocol that would detect common mistakes when 476 implementing IEEE 802 framing. 478 This specification therefore uses the ROHC encapsulation for also 479 carrying the negotiation payload. This is achieved by hijacking the 480 ROHC Add-CID packet types 11100001 to 11101111, see Figure 4; note 481 that R cannot be 0 (this would indicate a ROHC Padding byte). 482 Remaining_length gives the length of the negotiation payload and thus 483 echoes the LLC length (ROHC Length + 3) minus the 6 bytes consumed; 484 this serves as a check that the length was not damaged by a faulty 485 IEEE 802 implementation. (The ULE encapsulations are defined 486 analogously.) 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Destination MAC Address | 492 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 495 | Source MAC Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ROHC Length + 3 | ROHC SAP | ROHC SAP | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | 0x03 (UI) |1|1|1|0| R | Remaining_length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | negotiation payload... 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 4: ROHC negotiation packet including Ethernet MAC header 506 The negotiation payload defined in this specification looks exactly 507 like an RFC 3241 Robust Header Compression (ROHC) Option [RFC3241]. 508 If R is odd, it indicates the receiving capability of the originator 509 of the negotiation payload. If R is even, it indicates the actual 510 values that will be used in sending ROHC packets by the originator. 512 For unicast packets and where bidirectional connectivity is 513 available, a ROHC capable receiver SHOULD occasionally send 514 negotiation solicitation packets with R=1 to known neighbors, e.g. 515 triggered by the reception of ARP or ND packets or of actual data 516 packets (these negotiation solicitation packets MUST be strictly rate 517 limited and MUST NOT be sent unless activity is detected from a 518 neighbor). A ROHC capable sender MAY then send negotiation 519 advertisement packets with R=2; once bidirectional advertisement has 520 been achieved, the ROHC capable receiver SHOULD answer with its own 521 actual values used in sending ROHC packets in negotiation 522 advertisement packets with R=4 (no longer sending any R=2 packets). 523 Only when the negotiation advertisement packet exchange has been 524 completed SHOULD the ROHC capable sender start sending actual ROHC 525 packets instead of IP packets encapsulated the usual way. In the 526 spirit of IPv6 Neighbor Unreachability Detection (NUD [RFC4861]), the 527 negotiation exchanges should be repeated whenever it is unclear 528 whether the ROHC packets are successfully decompressed. 530 For multicast packets or for unidirectional connectivity, a ROHC 531 capable sender SHOULD send packets with R=6 to the MAC-layer 532 multicast address. ROHC receivers MUST NOT answer. There is no way 533 for a multicast/unidirectional sender to ascertain its receivers 534 indeed all support ROHC and are reached by ROHC packets. (Extensions 535 to IGMP/MLD could be defined to remedy this.) 537 For ROHC over 802, LARGE_CIDS is always set. ROHC capability is 538 always indicated for both IPv4 and IPv6. 540 7. Security Considerations 542 Making a node believe its peer node is ROHC capable when it isn't is 543 one way to stage a denial of service attack, as is maliciously 544 tearing down ROHC state. The ROHC negotiation protocol probably 545 needs to have security that is commensurate to that of the address 546 resolution/neighbor discovery protocol in use. (Extensions to 547 ICMPv6/SEND could be defined to make ROHC negotiation more secure.) 549 The ROHC protocol itself is quite susceptible to attacks. To quote 550 RFC 3095 [RFC3095]: 552 Denial-of-service attacks are possible if an intruder can 553 introduce (for example) bogus STATIC, DYNAMIC or FEEDBACK packets 554 onto the link and thereby cause compression efficiency to be 555 reduced. However, an intruder having the ability to inject 556 arbitrary packets at the link layer in this manner raises 557 additional security issues that dwarf those related to the use of 558 header compression. 560 8. References 562 8.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", 568 RFC 3241, April 2002. 570 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 571 Header Compression (ROHC) Framework", RFC 4995, July 2007. 573 8.2. Informative References 575 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 576 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 577 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 578 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 579 Compression (ROHC): Framework and four profiles: RTP, UDP, 580 ESP, and uncompressed", RFC 3095, July 2001. 582 [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 583 (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", 584 RFC 3242, April 2002. 586 [RFC3408] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional 587 Reliable Mode (R-mode) in Extended Link-Layer Assisted 588 RObust Header Compression (ROHC) Profile", RFC 3408, 589 December 2002. 591 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 592 (ROHC): A Compression Profile for IP", RFC 3843, 593 June 2004. 595 [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles 596 for User Datagram Protocol (UDP) Lite", RFC 4019, 597 April 2005. 599 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 600 and R. Wheeler, "A Method for Transmitting PPP Over 601 Ethernet (PPPoE)", RFC 2516, February 1999. 603 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 604 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 605 February 1988. 607 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 608 Terminology and Channel Mapping Examples", RFC 3759, 609 April 2004. 611 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 612 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 613 UDP-Lite", RFC 5225, April 2008. 615 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 616 "RObust Header Compression (ROHC): A Profile for TCP/IP 617 (ROHC-TCP)", RFC 4996, July 2007. 619 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 620 Lightweight Encapsulation (ULE) for Transmission of IP 621 Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, 622 December 2005. 624 [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link 625 PPP", RFC 2686, September 1999. 627 [I-D.bormann-rohc-avt-crtp-profile] 628 Bormann, C., "A ROHC Profile for CRTP (ROHC-CRTP)", 629 draft-bormann-rohc-avt-crtp-profile-00 (work in progress), 630 March 2007. 632 [refauth] "IEEE Logical Link Control Address & Standard Group MAC 633 Address Registration Authority", 634 . 636 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 637 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 638 September 2007. 640 Appendix A. Acknowledgements 642 The issue of enabling robust header compression over 802 networks has 643 been brought up repeatedly, e.g. by Kris Fleming in a contribution 644 called ROHCoWEM (draft-fleming-rohc-wireless-ethernet-med). The 645 participant comments at the Atlanta IETF ROHC WG meeting (November 646 2002) provided the basis for the analytical part of this document. 648 I would like to thank Bernard Aboba, Pedro Fortuna, Stephen McCann, 649 and Mike Morton for reviewing earlier versions of this document and 650 suppyling extremely useful comments. In particular, Bernard provided 651 a number of comments that proved useful for fleshing out Section 2.3. 652 (All errors, however, are mine.) 654 Author's Address 656 Carsten Bormann 657 Universitaet Bremen TZI 658 Postfach 330440 659 Bremen D-28334 660 Germany 662 Phone: +49 421 218 63921 663 Fax: +49 421 218 7000 664 Email: cabo@tzi.org