idnits 2.17.1 draft-ietf-ipv6-unicast-aggr-v2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2374, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: 'IPV6' is defined on line 133, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6RIR' ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Nokia 3 February 26, 2003 S. Deering, Cisco 4 E. Nordmark, Sun 6 IPv6 Global Unicast Address Format 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 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/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This internet draft expires on August 26, 2003. 33 Abstract 35 RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined 36 an IPv6 address allocation structure that includes TLA (Top Level 37 Aggregator) and NLA (Next Level Aggregator). This document replaces 38 RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. 40 1.0 Introduction 42 RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined 43 an IPv6 address allocation structure that includes TLA (Top Level 44 Aggregator) and NLA (Next Level Aggregator). This document replaces 45 RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. 47 2.0 TLA/NLA Made Historic 49 The TLA/NLA scheme has been replaced by a coordinated allocation 50 policy defined by the Regional Internet Registries (RIRs) [IPV6RIR]. 52 Part of the motivation for obsoleting the TLA/NLA structure is 53 technical; for instance, there is concern that TLA/NLA is not the 54 technically best approach at this stage of the deployment of IPv6. 55 Moreover, the allocation of IPv6 addresses is related to policy and 56 to the stewardship of the IP address space and routing table size, 57 which the RIRs have been managing for IPv4. It is likely that the 58 RIRs' policy will evolve as IPv6 deployment proceeds. 60 The IETF has provided technical input to the RIRs (for example, 61 [RFC3177]), which the RIRs have taken into account when defining 62 their address allocation policy. 64 RFC2374 was the definition of addresses for Format Prefix 001 65 (2000::/3) which is formally made historic by this document. Even 66 though currently only 2000::/3 is being delegated by the IANA, 67 implementations should not make any assumptions about 2000::/3 being 68 special, since the IANA might later be directed to delegate currently 69 unassigned parts of the IPv6 address space to the purpose of Global 70 Unicast as well. 72 The SLA (subnet local aggregator) field in RFC2374 remains in 73 function but with a different name in [ARCH]. Its new name is 74 "subnet ID". 76 This documented replaces RFC2374, "An IPv6 Aggregatable Global 77 Unicast Address Format". RFC2374 will become historic. 79 3.0 Address Format 81 The general format for IPv6 global unicast addresses as defined in 82 "IP Version 6 Addressing Architecture" [ARCH] is as follows: 84 | n bits | m bits | 128-n-m bits | 85 +-------------------------+-----------+----------------------------+ 86 | global routing prefix | subnet ID | interface ID | 87 +-------------------------+-----------+----------------------------+ 89 where the global routing prefix is a (typically hierarchically- 90 structured) value assigned to a site (a cluster of subnets/links), 91 the subnet ID is an identifier of a subnet within the site, and the 92 interface ID is as defined in section 2.5.1 of [ARCH]. 94 [ARCH] also requires that all unicast addresses, except those that 95 start with binary value 000, have Interface IDs that are 64 bits long 96 and to be constructed in Modified EUI-64 format. The format of 97 global unicast address in this case is: 99 | n bits | 64-n bits | 64 bits | 100 +-------------------------+-----------+----------------------------+ 101 | global routing prefix | subnet ID | interface ID | 102 +-------------------------+-----------+----------------------------+ 104 where the routing prefix is a value assigned to identify a site (a 105 cluster of subnets/links), the subnet ID is an identifier of a subnet 106 within the site, and the interface ID is in modified EUI-64 format as 107 defined in [ARCH]. 109 An example of the resulting format of global unicast address under 110 the 2000::/3 prefix that is currently being delegated by the IANA and 111 consistent with the recommendations in RFC3177 is: 113 | 3 | 45 bits | 16 bits | 64 bits | 114 +---+---------------------+-----------+----------------------------+ 115 |001|global routing prefix| subnet ID | interface ID | 116 +---+---------------------+-----------+----------------------------+ 118 4.0 Acknowledgments 120 The authors would like to express our thanks to Alain Durand, Brian 121 Carpenter, Fred Templin, Julian Sellers, Jun-ichiro itojun Hagino, 122 Margaret Wasserman, Michel Py, Pekka Savola, Tatuya Jinmei, and 123 Thomas Narten for their review and constructive comments. 125 5.0 References 127 Normative 129 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 130 Internet Draft, , 131 October 2002. 133 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 134 (IPv6) Specification", RFC2460, December 1998. 136 Non-Normative 138 [IPV6RIR] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and 139 Assignment Policy", Document ID: ripe-267, 140 http://www.ripe.net/ripe/docs/ipv6policy.html, January 22, 141 2003. 143 [RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to 144 Sites" RFC3177, September 2001. 146 6.0 Security Considerations 148 IPv6 addressing documents do not have any direct impact on Internet 149 infrastructure security. 151 7.0 Authors' Addresses 153 Robert M. Hinden email: bob.hinden@nokia.com 154 Nokia 155 313 Fairchild Drive 156 Mountain View, CA 157 US 158 Stephen E. Deering email: deering@cisco.com 159 Cisco Systems, Inc. 160 170 West Tasman Drive 161 San Jose, CA 95134-1706 162 US 164 Erik Nordmark email: erik.nordmark@sun.com 165 Sun Microsystems Laboratories 166 180, avenue de l'Europe 167 38334 SAINT ISMIER Cedex 168 France