idnits 2.17.1 draft-hui-6lowpan-hc1g-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 489. 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 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 (June 28, 2007) is 6147 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hui 3 Internet-Draft D. Culler 4 Intended status: Standards Track Arch Rock Corporation 5 Expires: December 30, 2007 June 28, 2007 7 Stateless IPv6 Header Compression for Globally Routable Packets in 8 6LoWPAN Subnetworks 9 draft-hui-6lowpan-hc1g-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 30, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies a stateless IP header compression scheme for 43 IPv6 packet delivery in 6LoWPAN subnetworks. The compression scheme 44 focuses on LoWPAN nodes that may have global unicast addresses 45 assigned to their interfaces. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 2. Header Compression . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. LOWPAN_HC1g Encoding of IPv6 Header Fields . . . . . . . . 5 53 2.2. LOWPAN_HC2 Encoding of UDP Header Fields . . . . . . . . . 7 54 2.3. ICMP and TCP Header Compression . . . . . . . . . . . . . 7 55 3. Modified IEEE EUI-64 Interface Identifiers . . . . . . . . . . 8 56 4. 16-bit Short Addresses . . . . . . . . . . . . . . . . . . . . 8 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 12 65 1. Introduction 67 The IEEE 802.15.4 standard specifies an MTU of 128 bytes, including 68 the length byte [ieee802.15.4] on a 250 kbps wireless link. Because 69 the link MTU is small, in fact smaller than the required 1280-byte 70 MTU of IPv6 [RFC2460], and because bandwidth, memory, or power 71 resources are critical in many IEEE 802.15.4 applications, 6LoWPAN 72 has defined an adaptation layer to support layer 3 (LOWPAN_HC1) and 73 layer 4 (LOWPAN_HC2) header compression, and sub-IP fragmentation, 74 for packet delivery over IEEE 802.15.4 links 75 [I-D.ietf-6lowpan-format]. Substantial portions of the headers are 76 elided, where they can be derived by the receiver from information 77 contained in the IEEE 802.15.4 frame with basic assumptions of shared 78 context. 80 The IPv6 addressing architecture supports a notion of scoping 81 [RFC4291]. Addresses defined within a scope must not extend beyond 82 their scope. Currently, IPv6 defines three unicast address scopes: 83 link-local, site-local, and global. Link-local addresses are 84 composed of a well-known 64-bit prefix and a 64-bit interface 85 identifier. Link-local addresses are intended for addressing on a 86 single link. They are commonly used for configuration protocols or 87 communication between nodes when no router exists. Site-local 88 addresses were originally intended for use within an 89 administratively-defined domain, but their use has since been 90 deprecated. Global addresses are intended for addressing any node 91 connected to the IPv6 network, including nodes within a local scope 92 once configured. A global address is composed of a n-bit global 93 routing prefix, m-bit subnet identifier, and a 128-n-m-bit interface 94 identifier. Global addresses not starting with a binary 000 are 95 required to have a 64-bit interface identifier, where n+m=64. 97 LOWPAN_HC1 supports eliding the prefix and/or interface identifier of 98 IPv6 source and destination addresses, but only for the link-local 99 prefix. Thus, for any LoWPAN node with a global unicast address 100 assigned to its 802.15.4 interface and using it for communication, 101 the full 128-bit address must be carried within packets to or from 102 the node. Carrying full source and destination addresses in an IEEE 103 802.15.4 packet consumes a quarter of the link-layer's MTU. This 104 overhead occurs in many important situations. For example, an IPv6 105 packet communicated between two nodes within a PAN, whether over a 106 single L2 hop or multiple L2 mesh-routed hops, utilizes extensive 107 header compression if their link-local addresses are specified, but 108 the same communication between the same nodes foregoes HC1 header 109 compression if their global address is specified. For monitoring 110 networks, the data collection point is often a machine that is 111 connected to the PAN by way of other non-802.15.4 links. Similarly, 112 in automation and control settings, the controller is often a machine 113 on existing IP links. Communication to and from nodes external to 114 the PAN utilize global address, so no HC1 header compression is 115 permitted, even when only a single IEEE 802.15.4 hop is involved. 116 Even where no other kinds of links are involved, IP routing among 117 nodes utilizing IEEE 803.15.4 links, as might occur among 802.15.4 118 subnets, perhaps using different PAN IDs, different channels, or 119 different MACs, cannot utilize HC1 header compression, because the 120 link-local address cannot be used. 122 This document specifies a stateless header compression scheme for 123 layer 3 (LOWPAN_HC1g) that allows compression of global unicast 124 addresses and permits existing compression of the layer 4 header. 125 Similar to LOWPAN_HC1, LOWPAN_HC1g recognizes that a prefix is shared 126 throughout the PAN, but in the LOWPAN_HC1g case it is a shared global 127 prefix, rather than the shared link local prefix. Indeed, link-local 128 communication is important to protocols like IPv6 Neighbor Discovery 129 [RFC2461] and LOWPAN_HC1 may be used to compress link-local 130 addresses. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. Header Compression 140 The LOWPAN_HC1g header compression scheme proposed in this section 141 maintains many of LOWPAN_HC1's design considerations. First, 142 LOWPAN_HC1g is a very simple and low-context form of header 143 compression. Second, it integrates layer 2 with layer 3 compression. 144 Finally, it also allows LoWPAN devices to send header compressed 145 packets via any of its neighbors, with as little preliminary context- 146 building as possible. 148 LOWPAN_HC1g operates directly on top of the basic LoWPAN header 149 formats defined in Section 5 of the 6LoWPAN format document. 150 LOWPAN_HC1g is identified by dispatch value 0x30, whereas LOWPAN_HC1 151 is identified by dispatch value 0x10. 153 Layer 4 header compression uses LOWPAN_HC2; the only, yet 154 significant, difference is where the layer 4 encoding bits appear in 155 the header stack. In LOWPAN_HC1g, the LOWPAN_HC2 encoding bits 156 immediately precede the uncompressed layer 4 fields. 158 Typical LOWPAN_HC1g/HC2 header configurations are shown in Figure 1. 160 +-------------------+--------------+--------------+----- 161 | HC1g Header | Uncompressed | Uncompressed | Data 162 | L4 Uncompressed | IP Fields | UDP Header | 163 +-------------------+--------------+--------------+----- 165 +-----------------+--------------+-------------+--------------+------ 166 | HC1g Header | Uncompressed | HC2 Header | Uncompressed | Data 167 | L4 Compressed | IP Fields | | UDP Fields | 168 +-----------------+--------------+-------------+--------------+------ 170 Figure 1: Typical LOWPAN_HC1g/HC2 Header Configurations 172 2.1. LOWPAN_HC1g Encoding of IPv6 Header Fields 174 The LOWPAN_HC1g header compression scheme supports the expected 175 common case on 6LoWPAN networks with no added overhead to LOWPAN_HC1. 176 Version is IPv6, Payload Length is derived from the 802.15.4 header 177 or "datagram_size" field from the fragmentation header, Traffic Class 178 and Flow Label are zero, Next Header is UDP, ICMP, or TCP, one or 179 both of IPv6 source and destination addresses are local to the PAN, 180 and the source and destination interface identifiers are derived 181 directly from the link-layer. The only field that cannot be 182 compressed is the Hops Left field. Thus, in the local case, the IP 183 header is compressed to 2 octets. 185 To support compression of global unicast addresses, LOWPAN_HC1g 186 assumes that a PAN is assigned one compressible 64-bit global IP 187 prefix. When either the source or destination address matches the 188 compressible global IP prefix, the prefix can be elided. Note that 189 additional global IP prefixes may be assigned to an interface, but 190 those prefixes are not compressible when using LOWPAN_HC1g. 192 Additionally, if interfaces are assigned a 64-bit interface 193 identifier, where the upper 49-bits is zero, the 64-bit global prefix 194 and the upper 48-bits of the interface identifier may be elided. 195 Such interface identifiers represent those with local scope, with the 196 universal/global bit set to "0". The 49th bit is not elided to 197 maintain alignment on octet boundaries. However, enforcing the 49th 198 bit to be "0", borrows from the 16-bit short address encoding 199 specified in I-D.ietf-6lowpan-format. [I-D.ietf-6lowpan-format] 200 Section 4 discusses how the encoding can be useful for commonly-used 201 multicast addresses. 203 The address compression encoding in LOWPAN_HC1g has four possible 204 forms: 206 Full 128-bit Address: Full 128-bit IPv6 address carried 207 unmodified in-line. 208 Compressed 64-bit Address: 64-bit prefix elided, 64-bit interface 209 identifier carried in-line. The 64-bit prefix is derived from 210 the 64-bit prefix assigned to the PAN. 211 Compressed 16-bit Address: 64-bit prefix elided, least 212 significant 16 bits of 64-bit interface identifier inline. The 213 64-bit prefix is derived from the 64-bit prefix assigned to the 214 PAN. The upper 48 bits of the interface identifier are assumed 215 to be all zeros. 216 Full 128-bit IPv6 address elided: The prefix identifier is 217 derived from the 64-bit global prefix assigned to the PAN. The 218 64-bit interface identifier is derived either from the LoWPAN 219 Mesh Addressing header or from the IEEE 802.15.4 link header. 220 The link-layer addresses used to derive the 64-bit interface 221 identifier is a short address, the short address describes the 222 lower 16 bits of the interface identifier. The upper 48 bits 223 are assumed to be all zeros. 225 The LOWPAN_HC1g encoding field is shown in Figure 2. 227 0 1 2 3 4 5 6 7 228 +---+---+---+---+---+---+---+---+ 229 | SC | DC |VTF| NH |L4C| 230 +---+---+---+---+---+---+---+---+ 232 Figure 2: LOWPAN_HC1g Header Compression Encoding 234 SC: IPv6 source address compression (bits 0 and 1): 235 00: Full 128-bit address 236 01: Compressed 64-bit address 237 10: Compressed 16-bit address 238 11: Full 128-bit IPv6 address elided 240 DC: IPv6 destination address compression (bits 2 and 3): 241 00: Full 128-bit address 242 01: Compressed 64-bit address 243 10: Compressed 16-bit address 244 11: Full 128-bit IPv6 address elided 246 VTF: Version, Traffic Class, and Flow Label (bit 4): 247 0: Full 4 bits for Version, 8 bits for Traffic Class, and 20 bits 248 for Flow Label are carried in-line. 249 1: Version, Traffic Class, and Flow Label are elided and assumed 250 to be zero. 252 NH: Next Header (bits 5 and 6): 253 00: Next header field carried in-line. 254 01: UDP 255 10: ICMP 256 11: TCP 258 L4C: Layer 4 Compression (bit 7): 259 0: Full layer 4 header is carried in-line. An HC2 encoding does 260 not precede the layer 4 header. 261 1: Layer 4 header is compressed. An HC2 encoding follows the IP 262 header but precedes the layer 4 header. Currently, this 263 indicator only supports UDP compression. 265 Of the fields in the IPv6 header, the uncompressed field that MUST 266 always be carried in-line is Hop Limit. Payload Length MUST never 267 appear, as it is always derived from the IEEE 802.15.4 header or the 268 "datagram_size" field in the LoWPAN fragmentation header. All other 269 fields, when carried in-line, MUST appear in the same order as 270 specified in RFC 2460 [RFC2460]. When all fields are carried in- 271 line, the header looks identical to a full IPv6 header without the 272 Payload Length field. This differs from LOWPAN_HC1, where fields do 273 not appear in this order. While it is possible to always assume IPv6 274 for the Version field, it is carried in-line whenever Traffic Class 275 and Flow Label are carried in-line. Not doing so will result in 276 field alignment not falling on an octet boundary. The actual next 277 header specified by the LOWPAN_HC1g encoding immediately follows all 278 IPv6 header fields carried in-line. 280 2.2. LOWPAN_HC2 Encoding of UDP Header Fields 282 Bit 7 in the LOWPAN_HC1g encoding specifies whether or not the layer 283 4 header is compressed. If layer 4 compression is specified, then 284 the LOWPAN_HC2g encoding replaces the uncompressed form of the layer 285 4 header. For UDP, the HC_UDP encoding scheme remains unchanged from 286 the 6LoWPAN format document [I-D.ietf-6lowpan-format]. The only 287 difference is that the HC_UDP encoding field immediately precedes the 288 in-line UDP fields, rather than sitting between the HC1 encoding and 289 in-line IPv6 fields. This co-locates the bits describing UDP headers 290 with the in-line fields. 292 2.3. ICMP and TCP Header Compression 294 This document does not specify a compression scheme for ICMP and TCP. 295 Such compression schemes may be specified in the future. 297 3. Modified IEEE EUI-64 Interface Identifiers 299 For LOWPAN_HC1g to compress a 128-bit address down to 16-bits, two 300 conditions must be satisfied: (i) the prefix matches the compressible 301 global prefix assigned to the PAN and (ii) the upper 49-bits of the 302 interface identifier must be zeros. This interface identifier is 303 constructed in Modified EUI-64 format, MUST have scope limited to the 304 assigned compressible global subnet-prefix, and MUST be subnet-prefix 305 unique. Included in the upper 49-bits is the universal/local bit, 306 which is set to "0" to indicate local scope. As suggested in RFC 307 4291 [RFC4291], possible approaches to select such a PAN-unique 308 interface identifier may include: 310 Manual Configuration 311 Node Serial Number 312 Other Node-Specific Token 314 4. 16-bit Short Addresses 316 [I-D.ietf-6lowpan-format] specifies an encoding for 16-bit short 317 addresses to be used in 6LoWPAN packets. The document reserves 318 0xffff (16-bit broadcast) and 0xfffe as defined in IEEE 802.15.4 319 [ieee802.15.4]. The document also specifies five different value 320 ranges. The lower 32,768 values are reserved for unicast addresses 321 and the next 8192 values are reserved for a link-layer multicast 322 address mapping. 324 This document allocates another range of 8192 values to be used for 325 commonly used, well-known IPv6 multicast addresses. By creating a 326 mapping between full 128-bit well-known multicast addresses to 16-bit 327 short addresses, commonly-used multicast addresses can be compressed 328 to 16-bits. The multicast mapping can be used with the 6LoWPAN Mesh 329 Delivery header or a LoWPAN_HC1g header by specifying use of the 16- 330 bit short address form. The encoding used for the 13-bits is as 331 follows: 333 0 1 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |Range| Scope | Mapped Group ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 3: LOWPAN_HC1g Header Compression Encoding 341 Range: 3-bit range identifier which indicates the use of a mapped 342 well-known IPv6 multicast address. 343 Scope: 4-bit multicast scope as specified in RFC 4007 [RFC4007]. 344 Mapped Group ID: 9-bit mapped multicast group identifier. 346 The full 128-bit multicast address can be reconstructed from the 16- 347 bit mapped multicast address. By definition, the 3-bit range 348 identifier indicates the well-known multicast prefix (0xFF) in 349 addition to a flags field set to all zeros (indicating a permanently 350 assigned multicast address, that the multicast address is not 351 assigned based on the network prefix, and that it doesn't embed the 352 address of a Rendezvous Point). The 4-bit scope is carried in-line 353 and the 112-bit group ID is derived from the 9-bit mapped group ID 354 using a well-known mapping maintained by the Internet Assigned 355 Numbers Authority (IANA). 357 This document defines an initial mapping. Additional mappings 358 between 9-bit mapped group IDs and 112-bit group IDs may be specified 359 in the future. 361 +-------+---------+-----------------------+ 362 | 9-bit | 112-bit | Description | 363 +-------+---------+-----------------------+ 364 | 1 | 1 | All Nodes Addresses | 365 | 2 | 2 | All Routers Addresses | 366 +-------+---------+-----------------------+ 368 9-bit to 128-bit Group ID Mapping 370 5. IANA Considerations 372 This document defines a new layer 3 header compression scheme for 373 6LoWPAN networks. The document allocate a new Dispatch type value of 374 0x30 that indicates the use of LOWPAN_HC1g. 376 This document requests another range, preferably Range 3 in the 16- 377 bit short address field specified in [I-D.ietf-6lowpan-format]. 379 This document creates a new IANA registry for mapped well-known 380 multicast addresses, mapping 112-bit group identifiers to compressed 381 9-bit ones. The registry MUST include the All Nodes Address (1) and 382 the All Routers Address (2). 384 6. Security Considerations 386 The definition of LOWPAN_HC1g permits the compression of header 387 information on communication that could take place in its absence, 388 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 389 PAN may have associated with it a global prefix. How that global 390 prefix is assigned and managed is beyond the scope of this document. 392 All drafts are required to have a security considerations section. 393 See RFC 3552 [RFC3552] for a guide. 395 7. References 397 7.1. Normative References 399 [I-D.ietf-6lowpan-format] 400 Montenegro, G., "Transmission of IPv6 Packets over IEEE 401 802.15.4 Networks", draft-ietf-6lowpan-format-13 (work in 402 progress), April 2007. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 408 (IPv6) Specification", RFC 2460, December 1998. 410 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 411 Discovery for IP Version 6 (IPv6)", RFC 2461, 412 December 1998. 414 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 415 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 416 March 2005. 418 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 419 Architecture", RFC 4291, February 2006. 421 [ieee802.15.4] 422 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 423 October 2006. 425 7.2. Informative References 427 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 428 Text on Security Considerations", BCP 72, RFC 3552, 429 July 2003. 431 Authors' Addresses 433 Jonathan W. Hui 434 Arch Rock Corporation 435 657 Mission St. Ste. 600 436 San Francisco, California 94105 437 USA 439 Phone: +415 692 0828 440 Email: jhui@archrock.com 442 David E. Culler 443 Arch Rock Corporation 444 657 Mission St. Ste. 600 445 San Francisco, California 94105 446 USA 448 Phone: +415 692 0828 449 Email: dculler@archrock.com 451 Full Copyright Statement 453 Copyright (C) The IETF Trust (2007). 455 This document is subject to the rights, licenses and restrictions 456 contained in BCP 78, and except as set forth therein, the authors 457 retain all their rights. 459 This document and the information contained herein are provided on an 460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 462 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 463 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 464 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 Intellectual Property 469 The IETF takes no position regarding the validity or scope of any 470 Intellectual Property Rights or other rights that might be claimed to 471 pertain to the implementation or use of the technology described in 472 this document or the extent to which any license under such rights 473 might or might not be available; nor does it represent that it has 474 made any independent effort to identify any such rights. Information 475 on the procedures with respect to rights in RFC documents can be 476 found in BCP 78 and BCP 79. 478 Copies of IPR disclosures made to the IETF Secretariat and any 479 assurances of licenses to be made available, or the result of an 480 attempt made to obtain a general license or permission for the use of 481 such proprietary rights by implementers or users of this 482 specification can be obtained from the IETF on-line IPR repository at 483 http://www.ietf.org/ipr. 485 The IETF invites any interested party to bring to its attention any 486 copyrights, patents or patent applications, or other proprietary 487 rights that may cover technology that may be required to implement 488 this standard. Please address the information to the IETF at 489 ietf-ipr@ietf.org. 491 Acknowledgment 493 Funding for the RFC Editor function is provided by the IETF 494 Administrative Support Activity (IASA).