idnits 2.17.1 draft-ietf-ipv6-ula-central-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 472. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The allocation of Global IDs should be pseudo-random [RANDOM]. They MUST not be assigned sequentially or with well known numbers. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally. Specifically, these prefixes are designed to not aggregate. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 114, but not defined == Unused Reference: 'GLOBAL' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'ICMPV6' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'POPUL' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'ADDAUTO' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'ADDSEL' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'DHCP6' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 407, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS' ** Downref: Normative reference to an Informational RFC: RFC 3587 (ref. 'GLOBAL') ** Obsolete normative reference: RFC 2463 (ref. 'ICMPV6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'POPUL' ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') -- Possible downref: Non-RFC (?) normative reference: ref. 'ULA' -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'ADDAUTO') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. 'ADDSEL') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'DHCP6') (Obsoleted by RFC 8415) Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Nokia 3 February 18, 2005 B. Haberman, JHU-APL 5 Centrally Assigned 6 Unique Local IPv6 Unicast Addresses 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This internet draft expires on August 23, 2005. 37 Abstract 39 This document defines Centrally allocated IPv6 Unique Local 40 addresses. These addresses are globally unique and are intended for 41 local communications, usually inside of a site. They are not 42 expected to be routable on the global Internet. 44 Table of Contents 46 1.0 Introduction....................................................2 47 2.0 Acknowledgments.................................................3 48 3.0 Local IPv6 Unicast Addresses....................................3 49 3.1 Format..........................................................3 50 3.2 Global ID.......................................................4 51 3.2.1 Centrally Assigned Global IDs.................................4 52 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6 53 4.0 Operational Guideliens..........................................6 54 5.0 Global Routing Considerations...................................7 55 5.1 From the Standpoint of the Internet.............................7 56 5.2 From the Standpoint of a Site...................................7 57 6.0 Security Considerations.........................................8 58 7.0 IANA Considerations.............................................8 59 8.0 References......................................................9 60 8.1 Normative References............................................9 61 8.2 Informative References..........................................9 62 9.0 Authors' Addresses.............................................10 63 10.0 Change Log....................................................11 64 11.0 Intellectual Property.........................................11 65 12.0 Disclaimer of Validity........................................12 66 13.0 Copyright Statement...........................................12 68 1.0 Introduction 70 This document defines the characteristics and technical allocation 71 requirements for centrally assigned Local IPv6 addresses in the 72 framework defined in [ULA]. They are not expected to be routable on 73 the global Internet. They are routable inside of a more limited area 74 such as a site. They may also be routed between a limited set of 75 sites. 77 Local IPv6 unicast addresses, as defined in [ULA], have the following 78 characteristics: 80 - Globally unique prefix. 81 - Well known prefix to allow for easy filtering at site 82 boundaries. 83 - Allows sites to be combined or privately interconnected without 84 creating any address conflicts or requiring renumbering of 85 interfaces using these prefixes. 86 - Internet Service Provider independent and can be used for 87 communications inside of a site without having any permanent or 88 intermittent Internet connectivity. 89 - If accidentally leaked outside of a site via routing or DNS, 90 there is no conflict with any other addresses. 92 - In practice, applications may treat these addresses like global 93 scoped addresses. 95 Topics that are general to all Local IPv6 address can be found in the 96 following sections of [ULA]: 98 3.3 Scope Definition 99 4.0 Operational Guidelines ** 100 4.1 Routing 101 4.2 Renumbering and Site Merging 102 4.3 Site Border Router and Firewall Packet Filtering 103 4.5 Application and Higher Level Protocol Issues 104 4.6 Use of Local IPv6 Addresses for Local Communications 105 4.7 Use of Local IPv6 Addresses with VPNs 106 6.0 Advantages and Disadvantages 108 ** Operational guidelines specific to centrally assigned Local IPv6 109 addresses are in Section 4.0 of this document. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC 2119]. 115 2.0 Acknowledgments 117 The authors would like to thank Brian Carpenter, Charlie Perkins, 118 Harald Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, 119 Alan Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian 120 Huitema, Tim Chown, Steve Bellovin, Alex Zinin, Tony Hain, Leslie 121 Daigle, and Bill Fenner for their comments and suggestions on this 122 document. 124 3.0 Centrally Assigned Local IPv6 Unicast Addresses 126 3.1 Format 128 The Centrally assigned Local IPv6 addresses, based on Unique Local 129 Addresses [ULA], have the following format: 131 | 7 bits |1| 40 bits | 16 bits | 64 bits | 132 +--------+-+------------+-----------+-----------------------------+ 133 | Prefix |L| Global ID | Subnet ID | Interface ID | 134 +--------+-+------------+-----------+-----------------------------+ 136 Where: 138 Prefix FC00::/7 prefix to identify Local IPv6 unicast 139 addresses. 141 L Set to 1 if the prefix is locally assigned, 142 Set to 0 if it is centrally assigned. See 143 Section 3.2 for additional information. 145 Global ID 40-bit global identifier used to create a 146 globally unique prefix. See Section 3.2 for 147 additional information. 149 Subnet ID 16-bit Subnet ID is an identifier of a subnet 150 within the site. 152 Interface ID 64-bit Interface ID as defined in [ADDARCH]. 154 3.2 Global ID 156 The allocation of Global IDs should be pseudo-random [RANDOM]. They 157 MUST not be assigned sequentially or with well known numbers. This 158 is to ensure that there is not any relationship between allocations 159 and to help clarify that these prefixes are not intended to be routed 160 globally. Specifically, these prefixes are designed to not 161 aggregate. 163 The major difference between the locally assigned Unique local 164 addresses defined in [ULA] and the centrally assigned local addresses 165 defined in this document is that they are uniquely assigned and the 166 assignments can be escrowed to resolve any disputes regarding 167 duplicate assignments. 169 It is expected that large managed sites will prefer central 170 assignments and small or disconnected sites will prefer local 171 assignments. It is recommended that sites planning to use Local IPv6 172 addresses for extensive inter-site communication, initially or as a 173 future possibility, use a centrally assigned prefix as there is no 174 possibility of assignment conflicts. Sites are free to choose either 175 approach. 177 This document defines the allocation procedure for creating global- 178 IDs for centrally assigned local IPv6 addresses (i.e., L=0). The 179 allocation procedure for locally assigned local IPv6 addresses (i.e., 180 L=1) is defined in [ULA]. 182 3.2.1 Centrally Assigned Global IDs 184 Centrally assigned Global IDs MUST be generated with a pseudo-random 185 algorithm consistent with [RANDOM]. They should not be assigned 186 sequentially or by locality. This is to ensure that there is no 187 relationship between allocations and to help clarify that these 188 prefixes are not intended to be routed globally by eliminating the 189 possibility of aggregation. Specifically, these prefixes are not 190 designed to aggregate. 192 Global IDs should be assigned under the authority of a single 193 allocation organization because they are pseudo-random and without 194 any structure. This is easiest to accomplish if there is a single 195 authority for the assignments. 197 The requirements for centrally assigned Global ID allocations are: 199 - Available to anyone in an unbiased manner. 200 - Permanent with no periodic fees. 201 - Allocation on a permanent basis, without any need for renewal 202 and without any procedure for de-allocation. 203 - Provide mechanisms that prevent hoarding of these allocations. 204 - The ownership of each individual allocation should be private, 205 but should be escrowed. 207 The allocation authority should permit allocations to be obtained 208 without having any sort of Internet connectivity. For example in 209 addition to web based registration they should support some methods 210 like telephone, postal mail, fax, etc. 212 The allocation service should include sufficient provisions to avoid 213 hoarding of numbers. This can be accomplished by various ways, for 214 example, requiring an exchange of documents, a verbal contact, or a 215 proof that the request is on behalf of a human rather than a machine. 216 The service may charge a small fee in order to cover its costs, but 217 the fee should be low enough to not create a barrier to anyone 218 needing one. The precise mechanisms should be decided by the 219 registration authority. 221 The ownership of the allocations is not needed to be public since the 222 resulting addresses are intended to be used for local communication. 223 It is escrowed to ensure there are no duplicate allocations and in 224 case it is needed in the future (e.g., to resolve duplicate 225 allocation disputes, or to support a change of the central allocation 226 authority). 228 Note, there are many possible ways of of creating an allocation 229 authority. It is important to keep in mind when reviewing 230 alternatives that the goal is to pick one that can do the job. It 231 doesn't have to be perfect, only good enough to do the job at hand. 233 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm 235 The algorithm described below is intended to be used for centrally 236 assigned Global IDs. In each case the resulting global ID will be 237 used in the appropriate prefix as defined in Section 3.2. 239 1) Obtain the current time of day in 64-bit NTP format [NTP]. 240 2) Obtain an EUI-64 identifier from the system running this 241 algorithm. If an EUI-64 does not exist, one can be created from 242 a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 243 cannot be obtained or created, a suitably unique identifier, 244 local to the node, should be used (e.g. system serial number). 245 3) Concatenate the time of day with the system-specific identifier 246 creating a key. 247 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; 248 the resulting value is 160 bits. 249 5) Use the least significant 40 bits as the Global ID. 250 6) Verify that the computed Global ID is not in the escrow. If it 251 is, discard the value and rerun the algorithm. 252 6) Concatenate FC00::/7, the L bit set to 0, and the 40 bit Global 253 ID to create a centrally assigned Local IPv6 address prefix. 255 This algorithm will result in a Global ID that is unique and can be 256 used to create a centrally assigned local IPv6 address prefix. 258 4.0 Operational Guidelines 260 4.1 DNS Issues 262 At the present time AAAA and PTR records for centrally assigned local 263 IPv6 addresses may be installed in the global DNS. This may be 264 useful if these addresses are being used for site to site or VPN 265 style applications, or for sites that wish to avoid separate DNS 266 systems for inside and outside traffic. 268 The operational issues relating to this are beyond the scope of this 269 document. 271 5.0 Global Routing Considerations 273 Section 4.1 of [ULA] provides operational guidelines that forbid 274 default routing of local addresses between sites. Concerns were 275 raised to the IPv6 working group and to the IETF as a whole that 276 sites may attempt to use local addresses as globally routed provider- 277 independent addresses. This section describes why using local 278 addresses as globally-routed provider-independent addresses is 279 unadvisable. 281 5.1 From the Standpoint of the Internet 283 There is a mismatch between the structure of IPv6 local addresses and 284 the normal IPv6 wide area routing model. The /48 prefix of an IPv6 285 local addresses fits nowhere in the normal hierarchy of IPv6 unicast 286 addresses. Normal IPv6 unicast addresses can be routed 287 hierarchically down to physical subnet (link) level and only have to 288 be flat-routed on the physical subnet. IPv6 local addresses would 289 have to be flat-routed even over the wide area Internet. 291 Thus, packets whose destination address is an IPv6 local address 292 could be routed over the wide area only if the corresponding /48 293 prefix were carried by the wide area routing protocol in use, such as 294 BGP. This contravenes the operational assumption that long prefixes 295 will be aggregated into many fewer short prefixes, to limit the table 296 size and convergence time of the routing protocol. If a network uses 297 both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these 298 types of address will certainly not aggregate with each other, since 299 they differ from the most significant bit onwards. Neither will IPv6 300 local addresses aggregate with each other, due to their random bit 301 patterns. This means that there would be a very significant 302 operational penalty for attempting to use IPv6 local address prefixes 303 generically with currently known wide area routing technology. 305 5.2 From the Standpoint of a Site 307 There are a number of design factors in IPv6 local addresses that 308 reduce the likelihood that IPv6 local addresses will be used as 309 arbitrary global unicast addresses. These include: 311 - The default rules to filter packets and routes make it very 312 difficult to use IPv6 local addresses for arbitrary use across 313 the Internet. For a site to use them as general purpose unicast 314 addresses, they would have to make sure that the default rules 315 were not being used by all other sites and intermediate ISPs 316 used for their current and future communication. 318 - They are not registered in public databases. The lack of public 319 registration creates operational problems. 321 - The addresses are allocated randomly. If a site had multiple 322 prefixes that they wanted to be used globally the cost of 323 advertising them would be very high as they could not be 324 aggregated. 326 - They have a long prefix (i.e, /48) so a single local address 327 prefix doesn't provide enough address space to be used 328 exclusively by the largest organizations. 330 6.0 Security Considerations 332 Local IPv6 addresses do not provide any inherent security to the 333 nodes that use them. They may be used with filters at site 334 boundaries to keep Local IPv6 traffic inside of the site, but this is 335 no more or less secure than filtering any other type of global IPv6 336 unicast addresses. 338 Local IPv6 addresses do allow for address-based security mechanisms, 339 including IPSEC, across end to end VPN connections. 341 7.0 IANA Considerations 343 The IANA is instructed to designate an allocation authority, based on 344 instructions from the IAB, for centrally assigned Unique Local IPv6 345 unicast addresses. This allocation authority shall comply with the 346 requirements described in Section 3.2 of this document, including in 347 particular allocation on a permanent basis and with sufficient 348 provisions to avoid hoarding of numbers. If deemed appropriate, the 349 authority may also consist of multiple organizations performing the 350 allocation authority duties. 352 The designated allocation authority is required to document how they 353 will meet the requirements described in Section 3.2 of this document 354 in an RFC. This RFC will be shepherd through the IETF by the IAB. 356 8.0 References 358 8.1 Normative References 360 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 361 Architecture", RFC 3515, April 2003. 363 [FIPS] "Federal Information Processing Standards Publication", 364 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 366 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 367 Address Format", RFC 3587, August 2003. 369 [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol 370 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 371 Specification", RFC2463, December 1998. 373 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 374 (IPv6) Specification", RFC 2460, December 1998. 376 [NTP] Mills, David L., "Network Time Protocol (Version 3) 377 Specification, Implementation and Analysis", RFC 1305, 378 March 1992. 380 [POPUL] Population Reference Bureau, "World Population Data Sheet 381 of the Population Reference Bureau 2002", August 2002. 383 [RANDOM] Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness 384 Recommendations for Security", RFC 1750, December 1994. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", RFC 2119, BCP14, March 1997. 389 [SHA1] D. Eastlake 3rd, P. Jones, "US Secure Hash Algorithm 1 390 (SHA1)", RFC 3174, September 2001. 392 [ULA] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast 393 Addresses", Internet Draft , November 2004. 396 8.2 Informative References 398 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 399 Autoconfiguration", RFC 2462, December 1998. 401 [ADDSEL] Draves, R., "Default Address Selection for Internet 402 Protocol version 6 (IPv6)", RFC 3484, February 2003. 404 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 405 for IPv6 (DHCPv6)", RFC3315, July 2003. 407 [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, 408 "RTP: A Transport Protocol for Real-Time Applications" 409 RFC3550, July 2003. 411 9.0 Authors' Addresses 413 Robert M. Hinden 414 Nokia 415 313 Fairchild Drive 416 Mountain View, CA 94043 417 USA 419 phone: +1 650 625-2004 420 email: bob.hinden@nokia.com 422 Brian Haberman 423 Johns Hopkins University 424 Applied Physics Lab 425 11100 Johns Hopkins Road 426 Laurel, MD 20723 427 USA 429 phone: +1 443 778 1319 430 email: brian@innovationslab.net 432 10.0 Change Log 434 Draft 436 o Revised to keep consistent with [ULA]. This includes single 437 prefix, L bit, change to SHA-1 algorithm, and clarifications to 438 suggested algorithm. 439 o Revised IANA considerations section based on feedback from the 440 IAB. 441 o Added new DNS operational guidelines sections specific to 442 centrally assigned local IPv6 addresses. 443 o Editorial changes. 445 Draft 447 o Initial Draft created from [ULA]. This draft defines the 448 centrally assigned Local IPv6 addresses. 450 11.0 Intellectual Property 452 The IETF takes no position regarding the validity or scope of any 453 Intellectual Property Rights or other rights that might be claimed to 454 pertain to the implementation or use of the technology described in 455 this document or the extent to which any license under such rights 456 might or might not be available; nor does it represent that it has 457 made any independent effort to identify any such rights. Information 458 on the procedures with respect to rights in RFC documents can be 459 found in BCP 78 and BCP 79. 461 Copies of IPR disclosures made to the IETF Secretariat and any 462 assurances of licenses to be made available, or the result of an 463 attempt made to obtain a general license or permission for the use of 464 such proprietary rights by implementers or users of this 465 specification can be obtained from the IETF on-line IPR repository at 466 http://www.ietf.org/ipr. 468 The IETF invites any interested party to bring to its attention any 469 copyrights, patents or patent applications, or other proprietary 470 rights that may cover technology that may be required to implement 471 this standard. Please address the information to the IETF at ietf- 472 ipr@ietf.org. 474 12.0 Disclaimer of Validity 476 This document and the information contained herein are provided on an 477 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 478 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 479 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 480 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 481 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 482 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 484 13.0 Copyright Statement 486 Copyright (C) The Internet Society (2004). This document is subject 487 to the rights, licenses and restrictions contained in BCP 78, and 488 except as set forth therein, the authors retain all their rights.