From: Guido Serassio Date: Sun, 29 Jun 2008 18:17:11 +0000 (+0200) Subject: Changed text file format from DOS to Unix X-Git-Tag: SQUID_3_0_STABLE8~32 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3b2c828f3503d10edeec883cf99c51dee3a67e6f;p=thirdparty%2Fsquid.git Changed text file format from DOS to Unix --- diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt old mode 100644 new mode 100755 index d137ef2f28..dac0e11c15 --- a/doc/rfc/rfc3226.txt +++ b/doc/rfc/rfc3226.txt @@ -1,339 +1,339 @@ - - - - - - -Network Working Group O. Gudmundsson -Request for Comments: 3226 December 2001 -Updates: 2874, 2535 -Category: Standards Track - - - DNSSEC and IPv6 A6 aware server/resolver message size requirements - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document mandates support for EDNS0 (Extension Mechanisms for - DNS) in DNS entities claiming to support either DNS Security - Extensions or A6 records. This requirement is necessary because - these new features increase the size of DNS messages. If EDNS0 is - not supported fall back to TCP will happen, having a detrimental - impact on query latency and DNS server load. This document updates - RFC 2535 and RFC 2874, by adding new requirements. - -1. Introduction - - Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions - [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. - - STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP - have a data payload of 512 octets or less. Most DNS software today - will not accept larger UDP datagrams. Any answer that requires more - than 512 octets, results in a partial and sometimes useless reply - with the Truncation Bit set; in most cases the requester will then - retry using TCP. Furthermore, server delivery of truncated responses - varies widely and resolver handling of these responses also varies, - leading to additional inefficiencies in handling truncation. - - Compared to UDP, TCP is an expensive protocol to use for a simple - transaction like DNS: a TCP connection requires 5 packets for setup - and tear down, excluding data packets, thus requiring at least 3 - round trips on top of the one for the original UDP query. The DNS - - - -Gudmundsson Standards Track [Page 1] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - - server also needs to keep a state of the connection during this - transaction. Many DNS servers answer thousands of queries per - second, requiring them to use TCP will cause significant overhead and - delays. - -1.1. Requirements - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in RFC 2119. - -2. Motivating factors - -2.1. DNSSEC motivations - - DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each - RR set. These signatures range in size from about 80 octets to 800 - octets, most are going to be in the range of 80 to 200 octets. The - addition of signatures on each or most RR sets in an answer - significantly increases the size of DNS answers from secure zones. - - For performance reasons and to reduce load on DNS servers, it is - important that security aware servers and resolvers get all the data - in Answer and Authority section in one query without truncation. - Sending Additional Data in the same query is helpful when the server - is authoritative for the data, and this reduces round trips. - - DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that - it is interested in receiving DNSSEC records. The OK bit does not - eliminate the need for large answers for DNSSEC capable clients. - -2.1.1. Message authentication or TSIG motivation - - TSIG [RFC2845] allows for the light weight authentication of DNS - messages, but increases the size of the messages by at least 70 - octets. DNSSEC specifies for computationally expensive message - authentication SIG(0) using a standard public key signature. As only - one TSIG or SIG(0) can be attached to each DNS answer the size - increase of message authentication is not significant, but may still - lead to a truncation. - -2.2. IPv6 Motivations - - IPv6 addresses [RFC2874] are 128 bits and can be represented in the - DNS by multiple A6 records, each consisting of a domain name and a - bit field. The domain name refers to an address prefix that may - require additional A6 RRs to be included in the answer. Answers - where the queried name has multiple A6 addresses may overflow a 512- - octet UDP packet size. - - - -Gudmundsson Standards Track [Page 2] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -2.3. Root server and TLD server motivations - - The current number of root servers is limited to 13 as that is the - maximum number of name servers and their address records that fit in - one 512-octet answer for a SOA record. If root servers start - advertising A6 or KEY records then the answer for the root NS records - will not fit in a single 512-octet DNS message, resulting in a large - number of TCP query connections to the root servers. Even if all - client resolver query their local name server for information, there - are millions of these servers. Each name server must periodically - update its information about the high level servers. - - For redundancy, latency and load balancing reasons, large numbers of - DNS servers are required for some zones. Since the root zone is used - by the entire net, it is important to have as many servers as - possible. Large TLDs (and many high-visibility SLDs) often have - enough servers that either A6 or KEY records would cause the NS - response to overflow the 512 byte limit. Note that these zones with - large numbers of servers are often exactly those zones that are - critical to network operation and that already sustain fairly high - loads. - -2.4. UDP vs TCP for DNS messages - - Given all these factors, it is essential that any implementation that - supports DNSSEC and or A6 be able to use larger DNS messages than 512 - octets. - - The original 512 restriction was put in place to reduce the - probability of fragmentation of DNS responses. A fragmented UDP - message that suffers a loss of one of the fragments renders the - answer useless and the query must be retried. A TCP connection - requires a larger number of round trips for establishment, data - transfer and tear down, but only the lost data segments are - retransmitted. - - In the early days a number of IP implementations did not handle - fragmentation well, but all modern operating systems have overcome - that issue thus sending fragmented messages is fine from that - standpoint. The open issue is the effect of losses on fragmented - messages. If connection has high loss ratio only TCP will allow - reliable transfer of DNS data, most links have low loss ratios thus - sending fragmented UDP packet in one round trip is better than - establishing a TCP connection to transfer a few thousand octets. - - - - - - - -Gudmundsson Standards Track [Page 3] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -2.5. EDNS0 and large UDP messages - - EDNS0 [RFC2671] allows clients to declare the maximum size of UDP - message they are willing to handle. Thus, if the expected answer is - between 512 octets and the maximum size that the client can accept, - the additional overhead of a TCP connection can be avoided. - -3. Protocol changes: - - This document updates RFC 2535 and RFC 2874, by adding new - requirements. - - All RFC 2535 compliant servers and resolvers MUST support EDNS0 and - advertise message size of at least 1220 octets, but SHOULD advertise - message size of 4000. This value might be too low to get full - answers for high level servers and successor of this document may - require a larger value. - - All RFC 2874 compliant servers and resolver MUST support EDNS0 and - advertise message size of at least 1024 octets, but SHOULD advertise - message size of 2048. The IPv6 datagrams should be 1024 octets, - unless the MTU of the path is known. (Note that this is smaller than - the minimum IPv6 MTU to allow for some extension headers and/or - encapsulation without exceeding the minimum MTU.) - - All RFC 2535 and RFC 2874 compliant entities MUST be able to handle - fragmented IPv4 and IPv6 UDP packets. - - All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger - required value in EDNS0 advertisements. - -4. Acknowledgments - - Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas - Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis - Michael Patton and Kazu Yamamoto were instrumental in motivating and - shaping this document. - -5. Security Considerations: - - There are no additional security considerations other than those in - RFC 2671. - -6. IANA Considerations: - - None - - - - - -Gudmundsson Standards Track [Page 4] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -7. References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2000. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - -8. Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC 20015 - USA - - EMail: ogud@ogud.com - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 5] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 6] - + + + + + + +Network Working Group O. Gudmundsson +Request for Comments: 3226 December 2001 +Updates: 2874, 2535 +Category: Standards Track + + + DNSSEC and IPv6 A6 aware server/resolver message size requirements + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document mandates support for EDNS0 (Extension Mechanisms for + DNS) in DNS entities claiming to support either DNS Security + Extensions or A6 records. This requirement is necessary because + these new features increase the size of DNS messages. If EDNS0 is + not supported fall back to TCP will happen, having a detrimental + impact on query latency and DNS server load. This document updates + RFC 2535 and RFC 2874, by adding new requirements. + +1. Introduction + + Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions + [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. + + STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP + have a data payload of 512 octets or less. Most DNS software today + will not accept larger UDP datagrams. Any answer that requires more + than 512 octets, results in a partial and sometimes useless reply + with the Truncation Bit set; in most cases the requester will then + retry using TCP. Furthermore, server delivery of truncated responses + varies widely and resolver handling of these responses also varies, + leading to additional inefficiencies in handling truncation. + + Compared to UDP, TCP is an expensive protocol to use for a simple + transaction like DNS: a TCP connection requires 5 packets for setup + and tear down, excluding data packets, thus requiring at least 3 + round trips on top of the one for the original UDP query. The DNS + + + +Gudmundsson Standards Track [Page 1] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + + server also needs to keep a state of the connection during this + transaction. Many DNS servers answer thousands of queries per + second, requiring them to use TCP will cause significant overhead and + delays. + +1.1. Requirements + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in RFC 2119. + +2. Motivating factors + +2.1. DNSSEC motivations + + DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each + RR set. These signatures range in size from about 80 octets to 800 + octets, most are going to be in the range of 80 to 200 octets. The + addition of signatures on each or most RR sets in an answer + significantly increases the size of DNS answers from secure zones. + + For performance reasons and to reduce load on DNS servers, it is + important that security aware servers and resolvers get all the data + in Answer and Authority section in one query without truncation. + Sending Additional Data in the same query is helpful when the server + is authoritative for the data, and this reduces round trips. + + DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that + it is interested in receiving DNSSEC records. The OK bit does not + eliminate the need for large answers for DNSSEC capable clients. + +2.1.1. Message authentication or TSIG motivation + + TSIG [RFC2845] allows for the light weight authentication of DNS + messages, but increases the size of the messages by at least 70 + octets. DNSSEC specifies for computationally expensive message + authentication SIG(0) using a standard public key signature. As only + one TSIG or SIG(0) can be attached to each DNS answer the size + increase of message authentication is not significant, but may still + lead to a truncation. + +2.2. IPv6 Motivations + + IPv6 addresses [RFC2874] are 128 bits and can be represented in the + DNS by multiple A6 records, each consisting of a domain name and a + bit field. The domain name refers to an address prefix that may + require additional A6 RRs to be included in the answer. Answers + where the queried name has multiple A6 addresses may overflow a 512- + octet UDP packet size. + + + +Gudmundsson Standards Track [Page 2] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.3. Root server and TLD server motivations + + The current number of root servers is limited to 13 as that is the + maximum number of name servers and their address records that fit in + one 512-octet answer for a SOA record. If root servers start + advertising A6 or KEY records then the answer for the root NS records + will not fit in a single 512-octet DNS message, resulting in a large + number of TCP query connections to the root servers. Even if all + client resolver query their local name server for information, there + are millions of these servers. Each name server must periodically + update its information about the high level servers. + + For redundancy, latency and load balancing reasons, large numbers of + DNS servers are required for some zones. Since the root zone is used + by the entire net, it is important to have as many servers as + possible. Large TLDs (and many high-visibility SLDs) often have + enough servers that either A6 or KEY records would cause the NS + response to overflow the 512 byte limit. Note that these zones with + large numbers of servers are often exactly those zones that are + critical to network operation and that already sustain fairly high + loads. + +2.4. UDP vs TCP for DNS messages + + Given all these factors, it is essential that any implementation that + supports DNSSEC and or A6 be able to use larger DNS messages than 512 + octets. + + The original 512 restriction was put in place to reduce the + probability of fragmentation of DNS responses. A fragmented UDP + message that suffers a loss of one of the fragments renders the + answer useless and the query must be retried. A TCP connection + requires a larger number of round trips for establishment, data + transfer and tear down, but only the lost data segments are + retransmitted. + + In the early days a number of IP implementations did not handle + fragmentation well, but all modern operating systems have overcome + that issue thus sending fragmented messages is fine from that + standpoint. The open issue is the effect of losses on fragmented + messages. If connection has high loss ratio only TCP will allow + reliable transfer of DNS data, most links have low loss ratios thus + sending fragmented UDP packet in one round trip is better than + establishing a TCP connection to transfer a few thousand octets. + + + + + + + +Gudmundsson Standards Track [Page 3] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.5. EDNS0 and large UDP messages + + EDNS0 [RFC2671] allows clients to declare the maximum size of UDP + message they are willing to handle. Thus, if the expected answer is + between 512 octets and the maximum size that the client can accept, + the additional overhead of a TCP connection can be avoided. + +3. Protocol changes: + + This document updates RFC 2535 and RFC 2874, by adding new + requirements. + + All RFC 2535 compliant servers and resolvers MUST support EDNS0 and + advertise message size of at least 1220 octets, but SHOULD advertise + message size of 4000. This value might be too low to get full + answers for high level servers and successor of this document may + require a larger value. + + All RFC 2874 compliant servers and resolver MUST support EDNS0 and + advertise message size of at least 1024 octets, but SHOULD advertise + message size of 2048. The IPv6 datagrams should be 1024 octets, + unless the MTU of the path is known. (Note that this is smaller than + the minimum IPv6 MTU to allow for some extension headers and/or + encapsulation without exceeding the minimum MTU.) + + All RFC 2535 and RFC 2874 compliant entities MUST be able to handle + fragmented IPv4 and IPv6 UDP packets. + + All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger + required value in EDNS0 advertisements. + +4. Acknowledgments + + Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas + Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis + Michael Patton and Kazu Yamamoto were instrumental in motivating and + shaping this document. + +5. Security Considerations: + + There are no additional security considerations other than those in + RFC 2671. + +6. IANA Considerations: + + None + + + + + +Gudmundsson Standards Track [Page 4] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +7. References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + +8. Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC 20015 + USA + + EMail: ogud@ogud.com + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 5] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 6] + diff --git a/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt old mode 100644 new mode 100755 index 7793621b0a..b5ca6a8e09 --- a/doc/rfc/rfc3513.txt +++ b/doc/rfc/rfc3513.txt @@ -1,1460 +1,1460 @@ - - - - - -Network Working Group R. Hinden -Request for Comments: 3513 Nokia -Obsoletes: 2373 S. Deering -Category: Standards Track Cisco Systems - April 2003 - - - Internet Protocol Version 6 (IPv6) Addressing Architecture - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This specification defines the addressing architecture of the IP - Version 6 (IPv6) protocol. The document includes the IPv6 addressing - model, text representations of IPv6 addresses, definition of IPv6 - unicast addresses, anycast addresses, and multicast addresses, and an - IPv6 node's required addresses. - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 1] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -Table of Contents - - 1. Introduction.................................................3 - 2. IPv6 Addressing..............................................3 - 2.1 Addressing Model.........................................4 - 2.2 Text Representation of Addresses.........................4 - 2.3 Text Representation of Address Prefixes..................5 - 2.4 Address Type Identification..............................6 - 2.5 Unicast Addresses........................................7 - 2.5.1 Interface Identifiers..............................8 - 2.5.2 The Unspecified Address............................9 - 2.5.3 The Loopback Address...............................9 - 2.5.4 Global Unicast Addresses..........................10 - 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10 - 2.5.6 Local-use IPv6 Unicast Addresses..................11 - 2.6 Anycast Addresses.......................................12 - 2.6.1 Required Anycast Address..........................13 - 2.7 Multicast Addresses.....................................13 - 2.7.1 Pre-Defined Multicast Addresses...................15 - 2.8 A Node's Required Addresses.............................17 - 3. Security Considerations.....................................17 - 4. IANA Considerations.........................................18 - 5. References..................................................19 - 5.1 Normative References....................................19 - 5.2 Informative References..................................19 - APPENDIX A: Creating Modified EUI-64 format Interface IDs......21 - APPENDIX B: Changes from RFC-2373..............................24 - Authors' Addresses.............................................25 - Full Copyright Statement.......................................26 - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 2] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -1. Introduction - - This specification defines the addressing architecture of the IP - Version 6 (IPv6) protocol. It includes the basic formats for the - various types of IPv6 addresses (unicast, anycast, and multicast). - - The authors would like to acknowledge the contributions of Paul - Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, - Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, - Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg - Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, - Sue Thomson, Markku Savela, and Larry Masinter. - -2. IPv6 Addressing - - IPv6 addresses are 128-bit identifiers for interfaces and sets of - interfaces (where "interface" is as defined in section 2 of [IPV6]). - There are three types of addresses: - - Unicast: An identifier for a single interface. A packet sent to a - unicast address is delivered to the interface identified - by that address. - - Anycast: An identifier for a set of interfaces (typically belonging - to different nodes). A packet sent to an anycast address - is delivered to one of the interfaces identified by that - address (the "nearest" one, according to the routing - protocols' measure of distance). - - Multicast: An identifier for a set of interfaces (typically belonging - to different nodes). A packet sent to a multicast address - is delivered to all interfaces identified by that address. - - There are no broadcast addresses in IPv6, their function being - superseded by multicast addresses. - - In this document, fields in addresses are given a specific name, for - example "subnet". When this name is used with the term "ID" for - identifier after the name (e.g., "subnet ID"), it refers to the - contents of the named field. When it is used with the term "prefix" - (e.g., "subnet prefix") it refers to all of the address from the left - up to and including this field. - - In IPv6, all zeros and all ones are legal values for any field, - unless specifically excluded. Specifically, prefixes may contain, or - end with, zero-valued fields. - - - - - -Hinden & Deering Standards Track [Page 3] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.1 Addressing Model - - IPv6 addresses of all types are assigned to interfaces, not nodes. - An IPv6 unicast address refers to a single interface. Since each - interface belongs to a single node, any of that node's interfaces' - unicast addresses may be used as an identifier for the node. - - All interfaces are required to have at least one link-local unicast - address (see section 2.8 for additional required addresses). A - single interface may also have multiple IPv6 addresses of any type - (unicast, anycast, and multicast) or scope. Unicast addresses with - scope greater than link-scope are not needed for interfaces that are - not used as the origin or destination of any IPv6 packets to or from - non-neighbors. This is sometimes convenient for point-to-point - interfaces. There is one exception to this addressing model: - - A unicast address or a set of unicast addresses may be assigned to - multiple physical interfaces if the implementation treats the - multiple physical interfaces as one interface when presenting it - to the internet layer. This is useful for load-sharing over - multiple physical interfaces. - - Currently IPv6 continues the IPv4 model that a subnet prefix is - associated with one link. Multiple subnet prefixes may be assigned - to the same link. - -2.2 Text Representation of Addresses - - There are three conventional forms for representing IPv6 addresses as - text strings: - - 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the - hexadecimal values of the eight 16-bit pieces of the address. - - Examples: - - FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 - - 1080:0:0:0:8:800:200C:417A - - Note that it is not necessary to write the leading zeros in an - individual field, but there must be at least one numeral in every - field (except for the case described in 2.). - - 2. Due to some methods of allocating certain styles of IPv6 - addresses, it will be common for addresses to contain long strings - of zero bits. In order to make writing addresses containing zero - bits easier a special syntax is available to compress the zeros. - - - -Hinden & Deering Standards Track [Page 4] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The use of "::" indicates one or more groups of 16 bits of zeros. - The "::" can only appear once in an address. The "::" can also be - used to compress leading or trailing zeros in an address. - - For example, the following addresses: - - 1080:0:0:0:8:800:200C:417A a unicast address - FF01:0:0:0:0:0:0:101 a multicast address - 0:0:0:0:0:0:0:1 the loopback address - 0:0:0:0:0:0:0:0 the unspecified addresses - - may be represented as: - - 1080::8:800:200C:417A a unicast address - FF01::101 a multicast address - ::1 the loopback address - :: the unspecified addresses - - 3. An alternative form that is sometimes more convenient when dealing - with a mixed environment of IPv4 and IPv6 nodes is - x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of - the six high-order 16-bit pieces of the address, and the 'd's are - the decimal values of the four low-order 8-bit pieces of the - address (standard IPv4 representation). Examples: - - 0:0:0:0:0:0:13.1.68.3 - - 0:0:0:0:0:FFFF:129.144.52.38 - - or in compressed form: - - ::13.1.68.3 - - ::FFFF:129.144.52.38 - -2.3 Text Representation of Address Prefixes - - The text representation of IPv6 address prefixes is similar to the - way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An - IPv6 address prefix is represented by the notation: - - ipv6-address/prefix-length - - where - - ipv6-address is an IPv6 address in any of the notations listed - in section 2.2. - - - - -Hinden & Deering Standards Track [Page 5] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - prefix-length is a decimal value specifying how many of the - leftmost contiguous bits of the address comprise - the prefix. - - For example, the following are legal representations of the 60-bit - prefix 12AB00000000CD3 (hexadecimal): - - 12AB:0000:0000:CD30:0000:0000:0000:0000/60 - 12AB::CD30:0:0:0:0/60 - 12AB:0:0:CD30::/60 - - The following are NOT legal representations of the above prefix: - - 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, - within any 16-bit chunk of the address - - 12AB::CD30/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:CD30 - - 12AB::CD3/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:0CD3 - - When writing both a node address and a prefix of that node address - (e.g., the node's subnet prefix), the two can combined as follows: - - the node address 12AB:0:0:CD30:123:4567:89AB:CDEF - and its subnet number 12AB:0:0:CD30::/60 - - can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 - -2.4 Address Type Identification - - The type of an IPv6 address is identified by the high-order bits of - the address, as follows: - - Address type Binary prefix IPv6 notation Section - ------------ ------------- ------------- ------- - Unspecified 00...0 (128 bits) ::/128 2.5.2 - Loopback 00...1 (128 bits) ::1/128 2.5.3 - Multicast 11111111 FF00::/8 2.7 - Link-local unicast 1111111010 FE80::/10 2.5.6 - Site-local unicast 1111111011 FEC0::/10 2.5.6 - Global unicast (everything else) - - Anycast addresses are taken from the unicast address spaces (of any - scope) and are not syntactically distinguishable from unicast - addresses. - - - - -Hinden & Deering Standards Track [Page 6] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The general format of global unicast addresses is described in - section 2.5.4. Some special-purpose subtypes of global unicast - addresses which contain embedded IPv4 addresses (for the purposes of - IPv4-IPv6 interoperation) are described in section 2.5.5. - - Future specifications may redefine one or more sub-ranges of the - global unicast space for other purposes, but unless and until that - happens, implementations must treat all addresses that do not start - with any of the above-listed prefixes as global unicast addresses. - -2.5 Unicast Addresses - - IPv6 unicast addresses are aggregable with prefixes of arbitrary - bit-length similar to IPv4 addresses under Classless Interdomain - Routing. - - There are several types of unicast addresses in IPv6, in particular - global unicast, site-local unicast, and link-local unicast. There - are also some special-purpose subtypes of global unicast, such as - IPv6 addresses with embedded IPv4 addresses or encoded NSAP - addresses. Additional address types or subtypes can be defined in - the future. - - IPv6 nodes may have considerable or little knowledge of the internal - structure of the IPv6 address, depending on the role the node plays - (for instance, host versus router). At a minimum, a node may - consider that unicast addresses (including its own) have no internal - structure: - - | 128 bits | - +-----------------------------------------------------------------+ - | node address | - +-----------------------------------------------------------------+ - - A slightly sophisticated host (but still rather simple) may - additionally be aware of subnet prefix(es) for the link(s) it is - attached to, where different addresses may have different values for - n: - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | interface ID | - +------------------------------------------------+----------------+ - - Though a very simple router may have no knowledge of the internal - structure of IPv6 unicast addresses, routers will more generally have - knowledge of one or more of the hierarchical boundaries for the - operation of routing protocols. The known boundaries will differ - - - -Hinden & Deering Standards Track [Page 7] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - from router to router, depending on what positions the router holds - in the routing hierarchy. - -2.5.1 Interface Identifiers - - Interface identifiers in IPv6 unicast addresses are used to identify - interfaces on a link. They are required to be unique within a subnet - prefix. It is recommended that the same interface identifier not be - assigned to different nodes on a link. They may also be unique over - a broader scope. In some cases an interface's identifier will be - derived directly from that interface's link-layer address. The same - interface identifier may be used on multiple interfaces on a single - node, as long as they are attached to different subnets. - - Note that the uniqueness of interface identifiers is independent of - the uniqueness of IPv6 addresses. For example, a global unicast - address may be created with a non-global scope interface identifier - and a site-local address may be created with a global scope interface - identifier. - - For all unicast addresses, except those that start with binary value - 000, Interface IDs are required to be 64 bits long and to be - constructed in Modified EUI-64 format. - - Modified EUI-64 format based Interface identifiers may have global - scope when derived from a global token (e.g., IEEE 802 48-bit MAC or - IEEE EUI-64 identifiers [EUI64]) or may have local scope where a - global token is not available (e.g., serial links, tunnel end-points, - etc.) or where global tokens are undesirable (e.g., temporary tokens - for privacy [PRIV]). - - Modified EUI-64 format interface identifiers are formed by inverting - the "u" bit (universal/local bit in IEEE EUI-64 terminology) when - forming the interface identifier from IEEE EUI-64 identifiers. In - the resulting Modified EUI-64 format the "u" bit is set to one (1) to - indicate global scope, and it is set to zero (0) to indicate local - scope. The first three octets in binary of an IEEE EUI-64 identifier - are as follows: - - 0 0 0 1 1 2 - |0 7 8 5 6 3| - +----+----+----+----+----+----+ - |cccc|ccug|cccc|cccc|cccc|cccc| - +----+----+----+----+----+----+ - - written in Internet standard bit-order , where "u" is the - universal/local bit, "g" is the individual/group bit, and "c" are the - bits of the company_id. Appendix A: "Creating Modified EUI-64 format - - - -Hinden & Deering Standards Track [Page 8] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - Interface Identifiers" provides examples on the creation of Modified - EUI-64 format based interface identifiers. - - The motivation for inverting the "u" bit when forming an interface - identifier is to make it easy for system administrators to hand - configure non-global identifiers when hardware tokens are not - available. This is expected to be case for serial links, tunnel end- - points, etc. The alternative would have been for these to be of the - form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, - etc. - - The use of the universal/local bit in the Modified EUI-64 format - identifier is to allow development of future technology that can take - advantage of interface identifiers with global scope. - - The details of forming interface identifiers are defined in the - appropriate "IPv6 over " specification such as "IPv6 over - Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. - -2.5.2 The Unspecified Address - - The address 0:0:0:0:0:0:0:0 is called the unspecified address. It - must never be assigned to any node. It indicates the absence of an - address. One example of its use is in the Source Address field of - any IPv6 packets sent by an initializing host before it has learned - its own address. - - The unspecified address must not be used as the destination address - of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a - source address of unspecified must never be forwarded by an IPv6 - router. - -2.5.3 The Loopback Address - - The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. - It may be used by a node to send an IPv6 packet to itself. It may - never be assigned to any physical interface. It is treated as - having link-local scope, and may be thought of as the link-local - unicast address of a virtual interface (typically called "the - loopback interface") to an imaginary link that goes nowhere. - - The loopback address must not be used as the source address in IPv6 - packets that are sent outside of a single node. An IPv6 packet with - a destination address of loopback must never be sent outside of a - single node and must never be forwarded by an IPv6 router. A packet - received on an interface with destination address of loopback must be - dropped. - - - - -Hinden & Deering Standards Track [Page 9] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.5.4 Global Unicast Addresses - - The general format for IPv6 global unicast addresses is as follows: - - | n bits | m bits | 128-n-m bits | - +------------------------+-----------+----------------------------+ - | global routing prefix | subnet ID | interface ID | - +------------------------+-----------+----------------------------+ - - where the global routing prefix is a (typically hierarchically- - structured) value assigned to a site (a cluster of subnets/links), - the subnet ID is an identifier of a link within the site, and the - interface ID is as defined in section 2.5.1. - - All global unicast addresses other than those that start with binary - 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as - described in section 2.5.1. Global unicast addresses that start with - binary 000 have no such constraint on the size or structure of the - interface ID field. - - Examples of global unicast addresses that start with binary 000 are - the IPv6 address with embedded IPv4 addresses described in section - 2.5.5 and the IPv6 address containing encoded NSAP addresses - specified in [NSAP]. An example of global addresses starting with a - binary value other than 000 (and therefore having a 64-bit interface - ID field) can be found in [AGGR]. - -2.5.5 IPv6 Addresses with Embedded IPv4 Addresses - - The IPv6 transition mechanisms [TRAN] include a technique for hosts - and routers to dynamically tunnel IPv6 packets over IPv4 routing - infrastructure. IPv6 nodes that use this technique are assigned - special IPv6 unicast addresses that carry a global IPv4 address in - the low-order 32 bits. This type of address is termed an "IPv4- - compatible IPv6 address" and has the format: - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|0000| IPv4 address | - +--------------------------------------+----+---------------------+ - - Note: The IPv4 address used in the "IPv4-compatible IPv6 address" - must be a globally-unique IPv4 unicast address. - - A second type of IPv6 address which holds an embedded IPv4 address is - also defined. This address type is used to represent the addresses - of IPv4 nodes as IPv6 addresses. This type of address is termed an - "IPv4-mapped IPv6 address" and has the format: - - - -Hinden & Deering Standards Track [Page 10] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|FFFF| IPv4 address | - +--------------------------------------+----+---------------------+ - -2.5.6 Local-Use IPv6 Unicast Addresses - - There are two types of local-use unicast addresses defined. These - are Link-Local and Site-Local. The Link-Local is for use on a single - link and the Site-Local is for use in a single site. Link-Local - addresses have the following format: - - | 10 | - | bits | 54 bits | 64 bits | - +----------+-------------------------+----------------------------+ - |1111111010| 0 | interface ID | - +----------+-------------------------+----------------------------+ - - Link-Local addresses are designed to be used for addressing on a - single link for purposes such as automatic address configuration, - neighbor discovery, or when no routers are present. - - Routers must not forward any packets with link-local source or - destination addresses to other links. - - Site-Local addresses have the following format: - - | 10 | - | bits | 54 bits | 64 bits | - +----------+-------------------------+----------------------------+ - |1111111011| subnet ID | interface ID | - +----------+-------------------------+----------------------------+ - - Site-local addresses are designed to be used for addressing inside of - a site without the need for a global prefix. Although a subnet ID - may be up to 54-bits long, it is expected that globally-connected - sites will use the same subnet IDs for site-local and global - prefixes. - - Routers must not forward any packets with site-local source or - destination addresses outside of the site. - - - - - - - - - - -Hinden & Deering Standards Track [Page 11] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.6 Anycast Addresses - - An IPv6 anycast address is an address that is assigned to more than - one interface (typically belonging to different nodes), with the - property that a packet sent to an anycast address is routed to the - "nearest" interface having that address, according to the routing - protocols' measure of distance. - - Anycast addresses are allocated from the unicast address space, using - any of the defined unicast address formats. Thus, anycast addresses - are syntactically indistinguishable from unicast addresses. When a - unicast address is assigned to more than one interface, thus turning - it into an anycast address, the nodes to which the address is - assigned must be explicitly configured to know that it is an anycast - address. - - For any assigned anycast address, there is a longest prefix P of that - address that identifies the topological region in which all - interfaces belonging to that anycast address reside. Within the - region identified by P, the anycast address must be maintained as a - separate entry in the routing system (commonly referred to as a "host - route"); outside the region identified by P, the anycast address may - be aggregated into the routing entry for prefix P. - - Note that in the worst case, the prefix P of an anycast set may be - the null prefix, i.e., the members of the set may have no topological - locality. In that case, the anycast address must be maintained as a - separate routing entry throughout the entire internet, which presents - a severe scaling limit on how many such "global" anycast sets may be - supported. Therefore, it is expected that support for global anycast - sets may be unavailable or very restricted. - - One expected use of anycast addresses is to identify the set of - routers belonging to an organization providing internet service. - Such addresses could be used as intermediate addresses in an IPv6 - Routing header, to cause a packet to be delivered via a particular - service provider or sequence of service providers. - - Some other possible uses are to identify the set of routers attached - to a particular subnet, or the set of routers providing entry into a - particular routing domain. - - There is little experience with widespread, arbitrary use of internet - anycast addresses, and some known complications and hazards when - using them in their full generality [ANYCST]. Until more experience - has been gained and solutions are specified, the following - restrictions are imposed on IPv6 anycast addresses: - - - - -Hinden & Deering Standards Track [Page 12] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - o An anycast address must not be used as the source address of an - IPv6 packet. - - o An anycast address must not be assigned to an IPv6 host, that is, - it may be assigned to an IPv6 router only. - -2.6.1 Required Anycast Address - - The Subnet-Router anycast address is predefined. Its format is as - follows: - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | 00000000000000 | - +------------------------------------------------+----------------+ - - The "subnet prefix" in an anycast address is the prefix which - identifies a specific link. This anycast address is syntactically - the same as a unicast address for an interface on the link with the - interface identifier set to zero. - - Packets sent to the Subnet-Router anycast address will be delivered - to one router on the subnet. All routers are required to support the - Subnet-Router anycast addresses for the subnets to which they have - interfaces. - - The subnet-router anycast address is intended to be used for - applications where a node needs to communicate with any one of the - set of routers. - -2.7 Multicast Addresses - - An IPv6 multicast address is an identifier for a group of interfaces - (typically on different nodes). An interface may belong to any - number of multicast groups. Multicast addresses have the following - format: - - | 8 | 4 | 4 | 112 bits | - +------ -+----+----+---------------------------------------------+ - |11111111|flgs|scop| group ID | - +--------+----+----+---------------------------------------------+ - - binary 11111111 at the start of the address identifies the - address as being a multicast address. - - +-+-+-+-+ - flgs is a set of 4 flags: |0|0|0|T| - +-+-+-+-+ - - - -Hinden & Deering Standards Track [Page 13] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The high-order 3 flags are reserved, and must be initialized - to 0. - - T = 0 indicates a permanently-assigned ("well-known") - multicast address, assigned by the Internet Assigned Number - Authority (IANA). - - T = 1 indicates a non-permanently-assigned ("transient") - multicast address. - - scop is a 4-bit multicast scope value used to limit the scope - of the multicast group. The values are: - - 0 reserved - 1 interface-local scope - 2 link-local scope - 3 reserved - 4 admin-local scope - 5 site-local scope - 6 (unassigned) - 7 (unassigned) - 8 organization-local scope - 9 (unassigned) - A (unassigned) - B (unassigned) - C (unassigned) - D (unassigned) - E global scope - F reserved - - interface-local scope spans only a single interface on a - node, and is useful only for loopback transmission of - multicast. - - link-local and site-local multicast scopes span the same - topological regions as the corresponding unicast scopes. - - admin-local scope is the smallest scope that must be - administratively configured, i.e., not automatically derived - from physical connectivity or other, non- multicast-related - configuration. - - organization-local scope is intended to span multiple sites - belonging to a single organization. - - scopes labeled "(unassigned)" are available for - administrators to define additional multicast regions. - - - - -Hinden & Deering Standards Track [Page 14] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - group ID identifies the multicast group, either permanent or - transient, within the given scope. - - The "meaning" of a permanently-assigned multicast address is - independent of the scope value. For example, if the "NTP servers - group" is assigned a permanent multicast address with a group ID of - 101 (hex), then: - - FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface - (i.e., the same node) as the sender. - - FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the - sender. - - FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the - sender. - - FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. - - Non-permanently-assigned multicast addresses are meaningful only - within a given scope. For example, a group identified by the non- - permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one - site bears no relationship to a group using the same address at a - different site, nor to a non-permanent group using the same group ID - with different scope, nor to a permanent group with the same group - ID. - - Multicast addresses must not be used as source addresses in IPv6 - packets or appear in any Routing header. - - Routers must not forward any multicast packets beyond of the scope - indicated by the scop field in the destination multicast address. - - Nodes must not originate a packet to a multicast address whose scop - field contains the reserved value 0; if such a packet is received, it - must be silently dropped. Nodes should not originate a packet to a - multicast address whose scop field contains the reserved value F; if - such a packet is sent or received, it must be treated the same as - packets destined to a global (scop E) multicast address. - -2.7.1 Pre-Defined Multicast Addresses - - The following well-known multicast addresses are pre-defined. The - group ID's defined in this section are defined for explicit scope - values. - - Use of these group IDs for any other scope values, with the T flag - equal to 0, is not allowed. - - - -Hinden & Deering Standards Track [Page 15] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 - FF01:0:0:0:0:0:0:0 - FF02:0:0:0:0:0:0:0 - FF03:0:0:0:0:0:0:0 - FF04:0:0:0:0:0:0:0 - FF05:0:0:0:0:0:0:0 - FF06:0:0:0:0:0:0:0 - FF07:0:0:0:0:0:0:0 - FF08:0:0:0:0:0:0:0 - FF09:0:0:0:0:0:0:0 - FF0A:0:0:0:0:0:0:0 - FF0B:0:0:0:0:0:0:0 - FF0C:0:0:0:0:0:0:0 - FF0D:0:0:0:0:0:0:0 - FF0E:0:0:0:0:0:0:0 - FF0F:0:0:0:0:0:0:0 - - The above multicast addresses are reserved and shall never be - assigned to any multicast group. - - All Nodes Addresses: FF01:0:0:0:0:0:0:1 - FF02:0:0:0:0:0:0:1 - - The above multicast addresses identify the group of all IPv6 nodes, - within scope 1 (interface-local) or 2 (link-local). - - All Routers Addresses: FF01:0:0:0:0:0:0:2 - FF02:0:0:0:0:0:0:2 - FF05:0:0:0:0:0:0:2 - - The above multicast addresses identify the group of all IPv6 routers, - within scope 1 (interface-local), 2 (link-local), or 5 (site-local). - - Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX - - Solicited-node multicast address are computed as a function of a - node's unicast and anycast addresses. A solicited-node multicast - address is formed by taking the low-order 24 bits of an address - (unicast or anycast) and appending those bits to the prefix - FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the - range - - FF02:0:0:0:0:1:FF00:0000 - - to - - FF02:0:0:0:0:1:FFFF:FFFF - - - - -Hinden & Deering Standards Track [Page 16] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - For example, the solicited node multicast address corresponding to - the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 - addresses that differ only in the high-order bits, e.g., due to - multiple high-order prefixes associated with different aggregations, - will map to the same solicited-node address thereby, reducing the - number of multicast addresses a node must join. - - A node is required to compute and join (on the appropriate interface) - the associated Solicited-Node multicast addresses for every unicast - and anycast address it is assigned. - -2.8 A Node's Required Addresses - - A host is required to recognize the following addresses as - identifying itself: - - o Its required Link-Local Address for each interface. - o Any additional Unicast and Anycast Addresses that have been - configured for the node's interfaces (manually or - automatically). - o The loopback address. - o The All-Nodes Multicast Addresses defined in section 2.7.1. - o The Solicited-Node Multicast Address for each of its unicast - and anycast addresses. - o Multicast Addresses of all other groups to which the node - belongs. - - A router is required to recognize all addresses that a host is - required to recognize, plus the following addresses as identifying - itself: - - o The Subnet-Router Anycast Addresses for all interfaces for - which it is configured to act as a router. - o All other Anycast Addresses with which the router has been - configured. - o The All-Routers Multicast Addresses defined in section 2.7.1. - -3. Security Considerations - - IPv6 addressing documents do not have any direct impact on Internet - infrastructure security. Authentication of IPv6 packets is defined - in [AUTH]. - - - - - - - - - -Hinden & Deering Standards Track [Page 17] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -4. IANA Considerations - - The table and notes at http://www.isi.edu/in- - notes/iana/assignments/ipv6-address-space.txt should be replaced with - the following: - - INTERNET PROTOCOL VERSION 6 ADDRESS SPACE - - The initial assignment of IPv6 address space is as follows: - - Allocation Prefix Fraction of - (binary) Address Space - ----------------------------------- -------- ------------- - Unassigned (see Note 1 below) 0000 0000 1/256 - Unassigned 0000 0001 1/256 - Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] - Unassigned 0000 01 1/64 - Unassigned 0000 1 1/32 - Unassigned 0001 1/16 - Global Unicast 001 1/8 [RFC2374] - Unassigned 010 1/8 - Unassigned 011 1/8 - Unassigned 100 1/8 - Unassigned 101 1/8 - Unassigned 110 1/8 - Unassigned 1110 1/16 - Unassigned 1111 0 1/32 - Unassigned 1111 10 1/64 - Unassigned 1111 110 1/128 - Unassigned 1111 1110 0 1/512 - Link-Local Unicast Addresses 1111 1110 10 1/1024 - Site-Local Unicast Addresses 1111 1110 11 1/1024 - Multicast Addresses 1111 1111 1/256 - - Notes: - - 1. The "unspecified address", the "loopback address", and the IPv6 - Addresses with Embedded IPv4 Addresses are assigned out of the - 0000 0000 binary prefix space. - - 2. For now, IANA should limit its allocation of IPv6 unicast address - space to the range of addresses that start with binary value 001. - The rest of the global unicast address space (approximately 85% of - the IPv6 address space) is reserved for future definition and use, - and is not to be assigned by IANA at this time. - - - - - - -Hinden & Deering Standards Track [Page 18] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -5. References - -5.1 Normative References - - [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9 , RFC 2026, October 1996. - -5.2 Informative References - - [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC - 2402, November 1998. - - [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable - Global Unicast Address Format", RFC 2374, July 1998. - - [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): An Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2464, December 1998. - - [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) - Registration Authority", - http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, - March 1997. - - [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI - Networks", RFC 2467, December 1998. - - [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address - Assignments", RFC 2375, July 1998. - - [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. - and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. - - [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless - Address Autoconfiguration in IPv6", RFC 3041, January 2001. - - [TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of - IPv6 Packets over Token Ring Networks", RFC 2470, December - 1998. - - - -Hinden & Deering Standards Track [Page 19] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 2893, August 2000. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 20] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -APPENDIX A: Creating Modified EUI-64 format Interface Identifiers - - Depending on the characteristics of a specific link or node there are - a number of approaches for creating Modified EUI-64 format interface - identifiers. This appendix describes some of these approaches. - -Links or Nodes with IEEE EUI-64 Identifiers - - The only change needed to transform an IEEE EUI-64 identifier to an - interface identifier is to invert the "u" (universal/local) bit. For - example, a globally unique IEEE EUI-64 identifier of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The IPv6 interface identifier would - be of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - The only change is inverting the value of the universal/local bit. - -Links or Nodes with IEEE 802 48 bit MAC's - - [EUI64] defines a method to create a IEEE EUI-64 identifier from an - IEEE 48bit MAC identifier. This is to insert two octets, with - hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC - (between the company_id and vendor supplied id). For example, the 48 - bit IEEE MAC with global scope: - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 21] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - |0 1|1 3|3 4| - |0 5|6 1|2 7| - +----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+ - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The interface identifier would be of - the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - When IEEE 802 48bit MAC addresses are available (on an interface or a - node), an implementation may use them to create interface identifiers - due to their availability and uniqueness properties. - -Links with Other Kinds of Identifiers - - There are a number of types of links that have link-layer interface - identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples - include LocalTalk and Arcnet. The method to create an Modified EUI- - 64 format identifier is to take the link identifier (e.g., the - LocalTalk 8 bit node identifier) and zero fill it to the left. For - example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F - results in the following interface identifier: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |0000000000000000|0000000000000000|0000000000000000|0000000001001111| - +----------------+----------------+----------------+----------------+ - - Note that this results in the universal/local bit set to "0" to - indicate local scope. - -Links without Identifiers - - There are a number of links that do not have any type of built-in - identifier. The most common of these are serial links and configured - tunnels. Interface identifiers must be chosen that are unique within - a subnet-prefix. - - - - -Hinden & Deering Standards Track [Page 22] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - When no built-in identifier is available on a link the preferred - approach is to use a global interface identifier from another - interface or one which is assigned to the node itself. When using - this approach no other interface connecting the same node to the same - subnet-prefix may use the same identifier. - - If there is no global interface identifier available for use on the - link the implementation needs to create a local-scope interface - identifier. The only requirement is that it be unique within a - subnet prefix. There are many possible approaches to select a - subnet-prefix-unique interface identifier. These include: - - Manual Configuration - Node Serial Number - Other node-specific token - - The subnet-prefix-unique interface identifier should be generated in - a manner that it does not change after a reboot of a node or if - interfaces are added or deleted from the node. - - The selection of the appropriate algorithm is link and implementation - dependent. The details on forming interface identifiers are defined - in the appropriate "IPv6 over " specification. It is strongly - recommended that a collision detection algorithm be implemented as - part of any automatic algorithm. - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 23] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -APPENDIX B: Changes from RFC-2373 - - The following changes were made from RFC-2373 "IP Version 6 - Addressing Architecture": - - - Clarified text in section 2.2 to allow "::" to represent one or - more groups of 16 bits of zeros. - - Changed uniqueness requirement of Interface Identifiers from - unique on a link to unique within a subnet prefix. Also added a - recommendation that the same interface identifier not be assigned - to different machines on a link. - - Change site-local format to make the subnet ID field 54-bit long - and remove the 38-bit zero's field. - - Added description of multicast scop values and rules to handle the - reserved scop value 0. - - Revised sections 2.4 and 2.5.6 to simplify and clarify how - different address types are identified. This was done to insure - that implementations do not build in any knowledge about global - unicast format prefixes. Changes include: - o Removed Format Prefix (FP) terminology - o Revised list of address types to only include exceptions to - global unicast and a singe entry that identifies everything - else as Global Unicast. - o Removed list of defined prefix exceptions from section 2.5.6 - as it is now the main part of section 2.4. - - Clarified text relating to EUI-64 identifiers to distinguish - between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI- - 64 identifiers. - - Combined the sections on the Global Unicast Addresses and NSAP - Addresses into a single section on Global Unicast Addresses, - generalized the Global Unicast format, and cited [AGGR] and [NSAP] - as examples. - - Reordered sections 2.5.4 and 2.5.5. - - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses - because this is being redefined elsewhere. - - Added an IANA considerations section that updates the IANA IPv6 - address allocations and documents the NSAP and AGGR allocations. - - Added clarification that the "IPv4-compatible IPv6 address" must - use global IPv4 unicast addresses. - - Divided references in to normative and non-normative sections. - - Added reference to [PRIV] in section 2.5.1 - - Added clarification that routers must not forward multicast - packets outside of the scope indicated in the multicast address. - - Added clarification that routers must not forward packets with - source address of the unspecified address. - - Added clarification that routers must drop packets received on an - interface with destination address of loopback. - - Clarified the definition of IPv4-mapped addresses. - - - -Hinden & Deering Standards Track [Page 24] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - - Removed the ABNF Description of Text Representations Appendix. - - Removed the address block reserved for IPX addresses. - - Multicast scope changes: - o Changed name of scope value 1 from "node-local" to - "interface-local" - o Defined scope value 4 as "admin-local" - - Corrected reference to RFC1933 and updated references. - - Many small changes to clarify and make the text more consistent. - -Authors' Addresses - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA - - Phone: +1 650 625-2004 - EMail: hinden@iprg.nokia.com - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: +1 408 527-8213 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 25] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 26] - - - + + + + + +Network Working Group R. Hinden +Request for Comments: 3513 Nokia +Obsoletes: 2373 S. Deering +Category: Standards Track Cisco Systems + April 2003 + + + Internet Protocol Version 6 (IPv6) Addressing Architecture + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This specification defines the addressing architecture of the IP + Version 6 (IPv6) protocol. The document includes the IPv6 addressing + model, text representations of IPv6 addresses, definition of IPv6 + unicast addresses, anycast addresses, and multicast addresses, and an + IPv6 node's required addresses. + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 1] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +Table of Contents + + 1. Introduction.................................................3 + 2. IPv6 Addressing..............................................3 + 2.1 Addressing Model.........................................4 + 2.2 Text Representation of Addresses.........................4 + 2.3 Text Representation of Address Prefixes..................5 + 2.4 Address Type Identification..............................6 + 2.5 Unicast Addresses........................................7 + 2.5.1 Interface Identifiers..............................8 + 2.5.2 The Unspecified Address............................9 + 2.5.3 The Loopback Address...............................9 + 2.5.4 Global Unicast Addresses..........................10 + 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10 + 2.5.6 Local-use IPv6 Unicast Addresses..................11 + 2.6 Anycast Addresses.......................................12 + 2.6.1 Required Anycast Address..........................13 + 2.7 Multicast Addresses.....................................13 + 2.7.1 Pre-Defined Multicast Addresses...................15 + 2.8 A Node's Required Addresses.............................17 + 3. Security Considerations.....................................17 + 4. IANA Considerations.........................................18 + 5. References..................................................19 + 5.1 Normative References....................................19 + 5.2 Informative References..................................19 + APPENDIX A: Creating Modified EUI-64 format Interface IDs......21 + APPENDIX B: Changes from RFC-2373..............................24 + Authors' Addresses.............................................25 + Full Copyright Statement.......................................26 + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 2] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +1. Introduction + + This specification defines the addressing architecture of the IP + Version 6 (IPv6) protocol. It includes the basic formats for the + various types of IPv6 addresses (unicast, anycast, and multicast). + + The authors would like to acknowledge the contributions of Paul + Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, + Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, + Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg + Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, + Sue Thomson, Markku Savela, and Larry Masinter. + +2. IPv6 Addressing + + IPv6 addresses are 128-bit identifiers for interfaces and sets of + interfaces (where "interface" is as defined in section 2 of [IPV6]). + There are three types of addresses: + + Unicast: An identifier for a single interface. A packet sent to a + unicast address is delivered to the interface identified + by that address. + + Anycast: An identifier for a set of interfaces (typically belonging + to different nodes). A packet sent to an anycast address + is delivered to one of the interfaces identified by that + address (the "nearest" one, according to the routing + protocols' measure of distance). + + Multicast: An identifier for a set of interfaces (typically belonging + to different nodes). A packet sent to a multicast address + is delivered to all interfaces identified by that address. + + There are no broadcast addresses in IPv6, their function being + superseded by multicast addresses. + + In this document, fields in addresses are given a specific name, for + example "subnet". When this name is used with the term "ID" for + identifier after the name (e.g., "subnet ID"), it refers to the + contents of the named field. When it is used with the term "prefix" + (e.g., "subnet prefix") it refers to all of the address from the left + up to and including this field. + + In IPv6, all zeros and all ones are legal values for any field, + unless specifically excluded. Specifically, prefixes may contain, or + end with, zero-valued fields. + + + + + +Hinden & Deering Standards Track [Page 3] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.1 Addressing Model + + IPv6 addresses of all types are assigned to interfaces, not nodes. + An IPv6 unicast address refers to a single interface. Since each + interface belongs to a single node, any of that node's interfaces' + unicast addresses may be used as an identifier for the node. + + All interfaces are required to have at least one link-local unicast + address (see section 2.8 for additional required addresses). A + single interface may also have multiple IPv6 addresses of any type + (unicast, anycast, and multicast) or scope. Unicast addresses with + scope greater than link-scope are not needed for interfaces that are + not used as the origin or destination of any IPv6 packets to or from + non-neighbors. This is sometimes convenient for point-to-point + interfaces. There is one exception to this addressing model: + + A unicast address or a set of unicast addresses may be assigned to + multiple physical interfaces if the implementation treats the + multiple physical interfaces as one interface when presenting it + to the internet layer. This is useful for load-sharing over + multiple physical interfaces. + + Currently IPv6 continues the IPv4 model that a subnet prefix is + associated with one link. Multiple subnet prefixes may be assigned + to the same link. + +2.2 Text Representation of Addresses + + There are three conventional forms for representing IPv6 addresses as + text strings: + + 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the + hexadecimal values of the eight 16-bit pieces of the address. + + Examples: + + FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 + + 1080:0:0:0:8:800:200C:417A + + Note that it is not necessary to write the leading zeros in an + individual field, but there must be at least one numeral in every + field (except for the case described in 2.). + + 2. Due to some methods of allocating certain styles of IPv6 + addresses, it will be common for addresses to contain long strings + of zero bits. In order to make writing addresses containing zero + bits easier a special syntax is available to compress the zeros. + + + +Hinden & Deering Standards Track [Page 4] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The use of "::" indicates one or more groups of 16 bits of zeros. + The "::" can only appear once in an address. The "::" can also be + used to compress leading or trailing zeros in an address. + + For example, the following addresses: + + 1080:0:0:0:8:800:200C:417A a unicast address + FF01:0:0:0:0:0:0:101 a multicast address + 0:0:0:0:0:0:0:1 the loopback address + 0:0:0:0:0:0:0:0 the unspecified addresses + + may be represented as: + + 1080::8:800:200C:417A a unicast address + FF01::101 a multicast address + ::1 the loopback address + :: the unspecified addresses + + 3. An alternative form that is sometimes more convenient when dealing + with a mixed environment of IPv4 and IPv6 nodes is + x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of + the six high-order 16-bit pieces of the address, and the 'd's are + the decimal values of the four low-order 8-bit pieces of the + address (standard IPv4 representation). Examples: + + 0:0:0:0:0:0:13.1.68.3 + + 0:0:0:0:0:FFFF:129.144.52.38 + + or in compressed form: + + ::13.1.68.3 + + ::FFFF:129.144.52.38 + +2.3 Text Representation of Address Prefixes + + The text representation of IPv6 address prefixes is similar to the + way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An + IPv6 address prefix is represented by the notation: + + ipv6-address/prefix-length + + where + + ipv6-address is an IPv6 address in any of the notations listed + in section 2.2. + + + + +Hinden & Deering Standards Track [Page 5] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + prefix-length is a decimal value specifying how many of the + leftmost contiguous bits of the address comprise + the prefix. + + For example, the following are legal representations of the 60-bit + prefix 12AB00000000CD3 (hexadecimal): + + 12AB:0000:0000:CD30:0000:0000:0000:0000/60 + 12AB::CD30:0:0:0:0/60 + 12AB:0:0:CD30::/60 + + The following are NOT legal representations of the above prefix: + + 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, + within any 16-bit chunk of the address + + 12AB::CD30/60 address to left of "/" expands to + 12AB:0000:0000:0000:0000:000:0000:CD30 + + 12AB::CD3/60 address to left of "/" expands to + 12AB:0000:0000:0000:0000:000:0000:0CD3 + + When writing both a node address and a prefix of that node address + (e.g., the node's subnet prefix), the two can combined as follows: + + the node address 12AB:0:0:CD30:123:4567:89AB:CDEF + and its subnet number 12AB:0:0:CD30::/60 + + can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 + +2.4 Address Type Identification + + The type of an IPv6 address is identified by the high-order bits of + the address, as follows: + + Address type Binary prefix IPv6 notation Section + ------------ ------------- ------------- ------- + Unspecified 00...0 (128 bits) ::/128 2.5.2 + Loopback 00...1 (128 bits) ::1/128 2.5.3 + Multicast 11111111 FF00::/8 2.7 + Link-local unicast 1111111010 FE80::/10 2.5.6 + Site-local unicast 1111111011 FEC0::/10 2.5.6 + Global unicast (everything else) + + Anycast addresses are taken from the unicast address spaces (of any + scope) and are not syntactically distinguishable from unicast + addresses. + + + + +Hinden & Deering Standards Track [Page 6] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The general format of global unicast addresses is described in + section 2.5.4. Some special-purpose subtypes of global unicast + addresses which contain embedded IPv4 addresses (for the purposes of + IPv4-IPv6 interoperation) are described in section 2.5.5. + + Future specifications may redefine one or more sub-ranges of the + global unicast space for other purposes, but unless and until that + happens, implementations must treat all addresses that do not start + with any of the above-listed prefixes as global unicast addresses. + +2.5 Unicast Addresses + + IPv6 unicast addresses are aggregable with prefixes of arbitrary + bit-length similar to IPv4 addresses under Classless Interdomain + Routing. + + There are several types of unicast addresses in IPv6, in particular + global unicast, site-local unicast, and link-local unicast. There + are also some special-purpose subtypes of global unicast, such as + IPv6 addresses with embedded IPv4 addresses or encoded NSAP + addresses. Additional address types or subtypes can be defined in + the future. + + IPv6 nodes may have considerable or little knowledge of the internal + structure of the IPv6 address, depending on the role the node plays + (for instance, host versus router). At a minimum, a node may + consider that unicast addresses (including its own) have no internal + structure: + + | 128 bits | + +-----------------------------------------------------------------+ + | node address | + +-----------------------------------------------------------------+ + + A slightly sophisticated host (but still rather simple) may + additionally be aware of subnet prefix(es) for the link(s) it is + attached to, where different addresses may have different values for + n: + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | interface ID | + +------------------------------------------------+----------------+ + + Though a very simple router may have no knowledge of the internal + structure of IPv6 unicast addresses, routers will more generally have + knowledge of one or more of the hierarchical boundaries for the + operation of routing protocols. The known boundaries will differ + + + +Hinden & Deering Standards Track [Page 7] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + from router to router, depending on what positions the router holds + in the routing hierarchy. + +2.5.1 Interface Identifiers + + Interface identifiers in IPv6 unicast addresses are used to identify + interfaces on a link. They are required to be unique within a subnet + prefix. It is recommended that the same interface identifier not be + assigned to different nodes on a link. They may also be unique over + a broader scope. In some cases an interface's identifier will be + derived directly from that interface's link-layer address. The same + interface identifier may be used on multiple interfaces on a single + node, as long as they are attached to different subnets. + + Note that the uniqueness of interface identifiers is independent of + the uniqueness of IPv6 addresses. For example, a global unicast + address may be created with a non-global scope interface identifier + and a site-local address may be created with a global scope interface + identifier. + + For all unicast addresses, except those that start with binary value + 000, Interface IDs are required to be 64 bits long and to be + constructed in Modified EUI-64 format. + + Modified EUI-64 format based Interface identifiers may have global + scope when derived from a global token (e.g., IEEE 802 48-bit MAC or + IEEE EUI-64 identifiers [EUI64]) or may have local scope where a + global token is not available (e.g., serial links, tunnel end-points, + etc.) or where global tokens are undesirable (e.g., temporary tokens + for privacy [PRIV]). + + Modified EUI-64 format interface identifiers are formed by inverting + the "u" bit (universal/local bit in IEEE EUI-64 terminology) when + forming the interface identifier from IEEE EUI-64 identifiers. In + the resulting Modified EUI-64 format the "u" bit is set to one (1) to + indicate global scope, and it is set to zero (0) to indicate local + scope. The first three octets in binary of an IEEE EUI-64 identifier + are as follows: + + 0 0 0 1 1 2 + |0 7 8 5 6 3| + +----+----+----+----+----+----+ + |cccc|ccug|cccc|cccc|cccc|cccc| + +----+----+----+----+----+----+ + + written in Internet standard bit-order , where "u" is the + universal/local bit, "g" is the individual/group bit, and "c" are the + bits of the company_id. Appendix A: "Creating Modified EUI-64 format + + + +Hinden & Deering Standards Track [Page 8] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + Interface Identifiers" provides examples on the creation of Modified + EUI-64 format based interface identifiers. + + The motivation for inverting the "u" bit when forming an interface + identifier is to make it easy for system administrators to hand + configure non-global identifiers when hardware tokens are not + available. This is expected to be case for serial links, tunnel end- + points, etc. The alternative would have been for these to be of the + form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, + etc. + + The use of the universal/local bit in the Modified EUI-64 format + identifier is to allow development of future technology that can take + advantage of interface identifiers with global scope. + + The details of forming interface identifiers are defined in the + appropriate "IPv6 over " specification such as "IPv6 over + Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. + +2.5.2 The Unspecified Address + + The address 0:0:0:0:0:0:0:0 is called the unspecified address. It + must never be assigned to any node. It indicates the absence of an + address. One example of its use is in the Source Address field of + any IPv6 packets sent by an initializing host before it has learned + its own address. + + The unspecified address must not be used as the destination address + of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a + source address of unspecified must never be forwarded by an IPv6 + router. + +2.5.3 The Loopback Address + + The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. + It may be used by a node to send an IPv6 packet to itself. It may + never be assigned to any physical interface. It is treated as + having link-local scope, and may be thought of as the link-local + unicast address of a virtual interface (typically called "the + loopback interface") to an imaginary link that goes nowhere. + + The loopback address must not be used as the source address in IPv6 + packets that are sent outside of a single node. An IPv6 packet with + a destination address of loopback must never be sent outside of a + single node and must never be forwarded by an IPv6 router. A packet + received on an interface with destination address of loopback must be + dropped. + + + + +Hinden & Deering Standards Track [Page 9] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.5.4 Global Unicast Addresses + + The general format for IPv6 global unicast addresses is as follows: + + | n bits | m bits | 128-n-m bits | + +------------------------+-----------+----------------------------+ + | global routing prefix | subnet ID | interface ID | + +------------------------+-----------+----------------------------+ + + where the global routing prefix is a (typically hierarchically- + structured) value assigned to a site (a cluster of subnets/links), + the subnet ID is an identifier of a link within the site, and the + interface ID is as defined in section 2.5.1. + + All global unicast addresses other than those that start with binary + 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as + described in section 2.5.1. Global unicast addresses that start with + binary 000 have no such constraint on the size or structure of the + interface ID field. + + Examples of global unicast addresses that start with binary 000 are + the IPv6 address with embedded IPv4 addresses described in section + 2.5.5 and the IPv6 address containing encoded NSAP addresses + specified in [NSAP]. An example of global addresses starting with a + binary value other than 000 (and therefore having a 64-bit interface + ID field) can be found in [AGGR]. + +2.5.5 IPv6 Addresses with Embedded IPv4 Addresses + + The IPv6 transition mechanisms [TRAN] include a technique for hosts + and routers to dynamically tunnel IPv6 packets over IPv4 routing + infrastructure. IPv6 nodes that use this technique are assigned + special IPv6 unicast addresses that carry a global IPv4 address in + the low-order 32 bits. This type of address is termed an "IPv4- + compatible IPv6 address" and has the format: + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|0000| IPv4 address | + +--------------------------------------+----+---------------------+ + + Note: The IPv4 address used in the "IPv4-compatible IPv6 address" + must be a globally-unique IPv4 unicast address. + + A second type of IPv6 address which holds an embedded IPv4 address is + also defined. This address type is used to represent the addresses + of IPv4 nodes as IPv6 addresses. This type of address is termed an + "IPv4-mapped IPv6 address" and has the format: + + + +Hinden & Deering Standards Track [Page 10] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|FFFF| IPv4 address | + +--------------------------------------+----+---------------------+ + +2.5.6 Local-Use IPv6 Unicast Addresses + + There are two types of local-use unicast addresses defined. These + are Link-Local and Site-Local. The Link-Local is for use on a single + link and the Site-Local is for use in a single site. Link-Local + addresses have the following format: + + | 10 | + | bits | 54 bits | 64 bits | + +----------+-------------------------+----------------------------+ + |1111111010| 0 | interface ID | + +----------+-------------------------+----------------------------+ + + Link-Local addresses are designed to be used for addressing on a + single link for purposes such as automatic address configuration, + neighbor discovery, or when no routers are present. + + Routers must not forward any packets with link-local source or + destination addresses to other links. + + Site-Local addresses have the following format: + + | 10 | + | bits | 54 bits | 64 bits | + +----------+-------------------------+----------------------------+ + |1111111011| subnet ID | interface ID | + +----------+-------------------------+----------------------------+ + + Site-local addresses are designed to be used for addressing inside of + a site without the need for a global prefix. Although a subnet ID + may be up to 54-bits long, it is expected that globally-connected + sites will use the same subnet IDs for site-local and global + prefixes. + + Routers must not forward any packets with site-local source or + destination addresses outside of the site. + + + + + + + + + + +Hinden & Deering Standards Track [Page 11] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +2.6 Anycast Addresses + + An IPv6 anycast address is an address that is assigned to more than + one interface (typically belonging to different nodes), with the + property that a packet sent to an anycast address is routed to the + "nearest" interface having that address, according to the routing + protocols' measure of distance. + + Anycast addresses are allocated from the unicast address space, using + any of the defined unicast address formats. Thus, anycast addresses + are syntactically indistinguishable from unicast addresses. When a + unicast address is assigned to more than one interface, thus turning + it into an anycast address, the nodes to which the address is + assigned must be explicitly configured to know that it is an anycast + address. + + For any assigned anycast address, there is a longest prefix P of that + address that identifies the topological region in which all + interfaces belonging to that anycast address reside. Within the + region identified by P, the anycast address must be maintained as a + separate entry in the routing system (commonly referred to as a "host + route"); outside the region identified by P, the anycast address may + be aggregated into the routing entry for prefix P. + + Note that in the worst case, the prefix P of an anycast set may be + the null prefix, i.e., the members of the set may have no topological + locality. In that case, the anycast address must be maintained as a + separate routing entry throughout the entire internet, which presents + a severe scaling limit on how many such "global" anycast sets may be + supported. Therefore, it is expected that support for global anycast + sets may be unavailable or very restricted. + + One expected use of anycast addresses is to identify the set of + routers belonging to an organization providing internet service. + Such addresses could be used as intermediate addresses in an IPv6 + Routing header, to cause a packet to be delivered via a particular + service provider or sequence of service providers. + + Some other possible uses are to identify the set of routers attached + to a particular subnet, or the set of routers providing entry into a + particular routing domain. + + There is little experience with widespread, arbitrary use of internet + anycast addresses, and some known complications and hazards when + using them in their full generality [ANYCST]. Until more experience + has been gained and solutions are specified, the following + restrictions are imposed on IPv6 anycast addresses: + + + + +Hinden & Deering Standards Track [Page 12] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + o An anycast address must not be used as the source address of an + IPv6 packet. + + o An anycast address must not be assigned to an IPv6 host, that is, + it may be assigned to an IPv6 router only. + +2.6.1 Required Anycast Address + + The Subnet-Router anycast address is predefined. Its format is as + follows: + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | 00000000000000 | + +------------------------------------------------+----------------+ + + The "subnet prefix" in an anycast address is the prefix which + identifies a specific link. This anycast address is syntactically + the same as a unicast address for an interface on the link with the + interface identifier set to zero. + + Packets sent to the Subnet-Router anycast address will be delivered + to one router on the subnet. All routers are required to support the + Subnet-Router anycast addresses for the subnets to which they have + interfaces. + + The subnet-router anycast address is intended to be used for + applications where a node needs to communicate with any one of the + set of routers. + +2.7 Multicast Addresses + + An IPv6 multicast address is an identifier for a group of interfaces + (typically on different nodes). An interface may belong to any + number of multicast groups. Multicast addresses have the following + format: + + | 8 | 4 | 4 | 112 bits | + +------ -+----+----+---------------------------------------------+ + |11111111|flgs|scop| group ID | + +--------+----+----+---------------------------------------------+ + + binary 11111111 at the start of the address identifies the + address as being a multicast address. + + +-+-+-+-+ + flgs is a set of 4 flags: |0|0|0|T| + +-+-+-+-+ + + + +Hinden & Deering Standards Track [Page 13] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + The high-order 3 flags are reserved, and must be initialized + to 0. + + T = 0 indicates a permanently-assigned ("well-known") + multicast address, assigned by the Internet Assigned Number + Authority (IANA). + + T = 1 indicates a non-permanently-assigned ("transient") + multicast address. + + scop is a 4-bit multicast scope value used to limit the scope + of the multicast group. The values are: + + 0 reserved + 1 interface-local scope + 2 link-local scope + 3 reserved + 4 admin-local scope + 5 site-local scope + 6 (unassigned) + 7 (unassigned) + 8 organization-local scope + 9 (unassigned) + A (unassigned) + B (unassigned) + C (unassigned) + D (unassigned) + E global scope + F reserved + + interface-local scope spans only a single interface on a + node, and is useful only for loopback transmission of + multicast. + + link-local and site-local multicast scopes span the same + topological regions as the corresponding unicast scopes. + + admin-local scope is the smallest scope that must be + administratively configured, i.e., not automatically derived + from physical connectivity or other, non- multicast-related + configuration. + + organization-local scope is intended to span multiple sites + belonging to a single organization. + + scopes labeled "(unassigned)" are available for + administrators to define additional multicast regions. + + + + +Hinden & Deering Standards Track [Page 14] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + group ID identifies the multicast group, either permanent or + transient, within the given scope. + + The "meaning" of a permanently-assigned multicast address is + independent of the scope value. For example, if the "NTP servers + group" is assigned a permanent multicast address with a group ID of + 101 (hex), then: + + FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface + (i.e., the same node) as the sender. + + FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the + sender. + + FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the + sender. + + FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. + + Non-permanently-assigned multicast addresses are meaningful only + within a given scope. For example, a group identified by the non- + permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one + site bears no relationship to a group using the same address at a + different site, nor to a non-permanent group using the same group ID + with different scope, nor to a permanent group with the same group + ID. + + Multicast addresses must not be used as source addresses in IPv6 + packets or appear in any Routing header. + + Routers must not forward any multicast packets beyond of the scope + indicated by the scop field in the destination multicast address. + + Nodes must not originate a packet to a multicast address whose scop + field contains the reserved value 0; if such a packet is received, it + must be silently dropped. Nodes should not originate a packet to a + multicast address whose scop field contains the reserved value F; if + such a packet is sent or received, it must be treated the same as + packets destined to a global (scop E) multicast address. + +2.7.1 Pre-Defined Multicast Addresses + + The following well-known multicast addresses are pre-defined. The + group ID's defined in this section are defined for explicit scope + values. + + Use of these group IDs for any other scope values, with the T flag + equal to 0, is not allowed. + + + +Hinden & Deering Standards Track [Page 15] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 + FF01:0:0:0:0:0:0:0 + FF02:0:0:0:0:0:0:0 + FF03:0:0:0:0:0:0:0 + FF04:0:0:0:0:0:0:0 + FF05:0:0:0:0:0:0:0 + FF06:0:0:0:0:0:0:0 + FF07:0:0:0:0:0:0:0 + FF08:0:0:0:0:0:0:0 + FF09:0:0:0:0:0:0:0 + FF0A:0:0:0:0:0:0:0 + FF0B:0:0:0:0:0:0:0 + FF0C:0:0:0:0:0:0:0 + FF0D:0:0:0:0:0:0:0 + FF0E:0:0:0:0:0:0:0 + FF0F:0:0:0:0:0:0:0 + + The above multicast addresses are reserved and shall never be + assigned to any multicast group. + + All Nodes Addresses: FF01:0:0:0:0:0:0:1 + FF02:0:0:0:0:0:0:1 + + The above multicast addresses identify the group of all IPv6 nodes, + within scope 1 (interface-local) or 2 (link-local). + + All Routers Addresses: FF01:0:0:0:0:0:0:2 + FF02:0:0:0:0:0:0:2 + FF05:0:0:0:0:0:0:2 + + The above multicast addresses identify the group of all IPv6 routers, + within scope 1 (interface-local), 2 (link-local), or 5 (site-local). + + Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX + + Solicited-node multicast address are computed as a function of a + node's unicast and anycast addresses. A solicited-node multicast + address is formed by taking the low-order 24 bits of an address + (unicast or anycast) and appending those bits to the prefix + FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the + range + + FF02:0:0:0:0:1:FF00:0000 + + to + + FF02:0:0:0:0:1:FFFF:FFFF + + + + +Hinden & Deering Standards Track [Page 16] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + For example, the solicited node multicast address corresponding to + the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 + addresses that differ only in the high-order bits, e.g., due to + multiple high-order prefixes associated with different aggregations, + will map to the same solicited-node address thereby, reducing the + number of multicast addresses a node must join. + + A node is required to compute and join (on the appropriate interface) + the associated Solicited-Node multicast addresses for every unicast + and anycast address it is assigned. + +2.8 A Node's Required Addresses + + A host is required to recognize the following addresses as + identifying itself: + + o Its required Link-Local Address for each interface. + o Any additional Unicast and Anycast Addresses that have been + configured for the node's interfaces (manually or + automatically). + o The loopback address. + o The All-Nodes Multicast Addresses defined in section 2.7.1. + o The Solicited-Node Multicast Address for each of its unicast + and anycast addresses. + o Multicast Addresses of all other groups to which the node + belongs. + + A router is required to recognize all addresses that a host is + required to recognize, plus the following addresses as identifying + itself: + + o The Subnet-Router Anycast Addresses for all interfaces for + which it is configured to act as a router. + o All other Anycast Addresses with which the router has been + configured. + o The All-Routers Multicast Addresses defined in section 2.7.1. + +3. Security Considerations + + IPv6 addressing documents do not have any direct impact on Internet + infrastructure security. Authentication of IPv6 packets is defined + in [AUTH]. + + + + + + + + + +Hinden & Deering Standards Track [Page 17] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +4. IANA Considerations + + The table and notes at http://www.isi.edu/in- + notes/iana/assignments/ipv6-address-space.txt should be replaced with + the following: + + INTERNET PROTOCOL VERSION 6 ADDRESS SPACE + + The initial assignment of IPv6 address space is as follows: + + Allocation Prefix Fraction of + (binary) Address Space + ----------------------------------- -------- ------------- + Unassigned (see Note 1 below) 0000 0000 1/256 + Unassigned 0000 0001 1/256 + Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] + Unassigned 0000 01 1/64 + Unassigned 0000 1 1/32 + Unassigned 0001 1/16 + Global Unicast 001 1/8 [RFC2374] + Unassigned 010 1/8 + Unassigned 011 1/8 + Unassigned 100 1/8 + Unassigned 101 1/8 + Unassigned 110 1/8 + Unassigned 1110 1/16 + Unassigned 1111 0 1/32 + Unassigned 1111 10 1/64 + Unassigned 1111 110 1/128 + Unassigned 1111 1110 0 1/512 + Link-Local Unicast Addresses 1111 1110 10 1/1024 + Site-Local Unicast Addresses 1111 1110 11 1/1024 + Multicast Addresses 1111 1111 1/256 + + Notes: + + 1. The "unspecified address", the "loopback address", and the IPv6 + Addresses with Embedded IPv4 Addresses are assigned out of the + 0000 0000 binary prefix space. + + 2. For now, IANA should limit its allocation of IPv6 unicast address + space to the range of addresses that start with binary value 001. + The rest of the global unicast address space (approximately 85% of + the IPv6 address space) is reserved for future definition and use, + and is not to be assigned by IANA at this time. + + + + + + +Hinden & Deering Standards Track [Page 18] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +5. References + +5.1 Normative References + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9 , RFC 2026, October 1996. + +5.2 Informative References + + [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable + Global Unicast Address Format", RFC 2374, July 1998. + + [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): An Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, December 1998. + + [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) + Registration Authority", + http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, + March 1997. + + [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI + Networks", RFC 2467, December 1998. + + [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address + Assignments", RFC 2375, July 1998. + + [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. + and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. + + [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless + Address Autoconfiguration in IPv6", RFC 3041, January 2001. + + [TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of + IPv6 Packets over Token Ring Networks", RFC 2470, December + 1998. + + + +Hinden & Deering Standards Track [Page 19] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 20] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +APPENDIX A: Creating Modified EUI-64 format Interface Identifiers + + Depending on the characteristics of a specific link or node there are + a number of approaches for creating Modified EUI-64 format interface + identifiers. This appendix describes some of these approaches. + +Links or Nodes with IEEE EUI-64 Identifiers + + The only change needed to transform an IEEE EUI-64 identifier to an + interface identifier is to invert the "u" (universal/local) bit. For + example, a globally unique IEEE EUI-64 identifier of the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the value + of the universal/local bit to indicate global scope, "g" is + individual/group bit, and "m" are the bits of the manufacturer- + selected extension identifier. The IPv6 interface identifier would + be of the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + The only change is inverting the value of the universal/local bit. + +Links or Nodes with IEEE 802 48 bit MAC's + + [EUI64] defines a method to create a IEEE EUI-64 identifier from an + IEEE 48bit MAC identifier. This is to insert two octets, with + hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC + (between the company_id and vendor supplied id). For example, the 48 + bit IEEE MAC with global scope: + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 21] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + |0 1|1 3|3 4| + |0 5|6 1|2 7| + +----------------+----------------+----------------+ + |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the value + of the universal/local bit to indicate global scope, "g" is + individual/group bit, and "m" are the bits of the manufacturer- + selected extension identifier. The interface identifier would be of + the form: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| + +----------------+----------------+----------------+----------------+ + + When IEEE 802 48bit MAC addresses are available (on an interface or a + node), an implementation may use them to create interface identifiers + due to their availability and uniqueness properties. + +Links with Other Kinds of Identifiers + + There are a number of types of links that have link-layer interface + identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples + include LocalTalk and Arcnet. The method to create an Modified EUI- + 64 format identifier is to take the link identifier (e.g., the + LocalTalk 8 bit node identifier) and zero fill it to the left. For + example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F + results in the following interface identifier: + + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |0000000000000000|0000000000000000|0000000000000000|0000000001001111| + +----------------+----------------+----------------+----------------+ + + Note that this results in the universal/local bit set to "0" to + indicate local scope. + +Links without Identifiers + + There are a number of links that do not have any type of built-in + identifier. The most common of these are serial links and configured + tunnels. Interface identifiers must be chosen that are unique within + a subnet-prefix. + + + + +Hinden & Deering Standards Track [Page 22] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + When no built-in identifier is available on a link the preferred + approach is to use a global interface identifier from another + interface or one which is assigned to the node itself. When using + this approach no other interface connecting the same node to the same + subnet-prefix may use the same identifier. + + If there is no global interface identifier available for use on the + link the implementation needs to create a local-scope interface + identifier. The only requirement is that it be unique within a + subnet prefix. There are many possible approaches to select a + subnet-prefix-unique interface identifier. These include: + + Manual Configuration + Node Serial Number + Other node-specific token + + The subnet-prefix-unique interface identifier should be generated in + a manner that it does not change after a reboot of a node or if + interfaces are added or deleted from the node. + + The selection of the appropriate algorithm is link and implementation + dependent. The details on forming interface identifiers are defined + in the appropriate "IPv6 over " specification. It is strongly + recommended that a collision detection algorithm be implemented as + part of any automatic algorithm. + + + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 23] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +APPENDIX B: Changes from RFC-2373 + + The following changes were made from RFC-2373 "IP Version 6 + Addressing Architecture": + + - Clarified text in section 2.2 to allow "::" to represent one or + more groups of 16 bits of zeros. + - Changed uniqueness requirement of Interface Identifiers from + unique on a link to unique within a subnet prefix. Also added a + recommendation that the same interface identifier not be assigned + to different machines on a link. + - Change site-local format to make the subnet ID field 54-bit long + and remove the 38-bit zero's field. + - Added description of multicast scop values and rules to handle the + reserved scop value 0. + - Revised sections 2.4 and 2.5.6 to simplify and clarify how + different address types are identified. This was done to insure + that implementations do not build in any knowledge about global + unicast format prefixes. Changes include: + o Removed Format Prefix (FP) terminology + o Revised list of address types to only include exceptions to + global unicast and a singe entry that identifies everything + else as Global Unicast. + o Removed list of defined prefix exceptions from section 2.5.6 + as it is now the main part of section 2.4. + - Clarified text relating to EUI-64 identifiers to distinguish + between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI- + 64 identifiers. + - Combined the sections on the Global Unicast Addresses and NSAP + Addresses into a single section on Global Unicast Addresses, + generalized the Global Unicast format, and cited [AGGR] and [NSAP] + as examples. + - Reordered sections 2.5.4 and 2.5.5. + - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses + because this is being redefined elsewhere. + - Added an IANA considerations section that updates the IANA IPv6 + address allocations and documents the NSAP and AGGR allocations. + - Added clarification that the "IPv4-compatible IPv6 address" must + use global IPv4 unicast addresses. + - Divided references in to normative and non-normative sections. + - Added reference to [PRIV] in section 2.5.1 + - Added clarification that routers must not forward multicast + packets outside of the scope indicated in the multicast address. + - Added clarification that routers must not forward packets with + source address of the unspecified address. + - Added clarification that routers must drop packets received on an + interface with destination address of loopback. + - Clarified the definition of IPv4-mapped addresses. + + + +Hinden & Deering Standards Track [Page 24] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + + - Removed the ABNF Description of Text Representations Appendix. + - Removed the address block reserved for IPX addresses. + - Multicast scope changes: + o Changed name of scope value 1 from "node-local" to + "interface-local" + o Defined scope value 4 as "admin-local" + - Corrected reference to RFC1933 and updated references. + - Many small changes to clarify and make the text more consistent. + +Authors' Addresses + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625-2004 + EMail: hinden@iprg.nokia.com + + + Stephen E. Deering + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + USA + + Phone: +1 408 527-8213 + EMail: deering@cisco.com + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 25] + +RFC 3513 IPv6 Addressing Architecture April 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 26] + + + diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt old mode 100644 new mode 100755 index 5e0be2ac1c..f65690c887 --- a/doc/rfc/rfc3596.txt +++ b/doc/rfc/rfc3596.txt @@ -1,451 +1,451 @@ - - - - - - -Network Working Group S. Thomson -Request for Comments: 3596 Cisco -Obsoletes: 3152, 1886 C. Huitema -Category: Standards Track Microsoft - V. Ksinant - 6WIND - M. Souissi - AFNIC - October 2003 - - - DNS Extensions to Support IP Version 6 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines the changes that need to be made to the Domain - Name System (DNS) to support hosts running IP version 6 (IPv6). The - changes include a resource record type to store an IPv6 address, a - domain to support lookups based on an IPv6 address, and updated - definitions of existing query types that return Internet addresses as - part of additional section processing. The extensions are designed - to be compatible with existing applications and, in particular, DNS - implementations themselves. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. New resource record definition and domain. . . . . . . . . . . 2 - 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 - 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 - 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 - 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 - 3. Modifications to existing query types. . . . . . . . . . . . . 4 - 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 - - - -Thomson, et al. Standards Track [Page 1] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - - 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 - Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 - Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 - Informative References . . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 - -1. Introduction - - Current support for the storage of Internet addresses in the Domain - Name System (DNS) [1,2] cannot easily be extended to support IPv6 - addresses [3] since applications assume that address queries return - 32-bit IPv4 addresses only. - - To support the storage of IPv6 addresses in the DNS, this document - defines the following extensions: - - o A resource record type is defined to map a domain name to an - IPv6 address. - - o A domain is defined to support lookups based on address. - - o Existing queries that perform additional section processing to - locate IPv4 addresses are redefined to perform additional - section processing on both IPv4 and IPv6 addresses. - - The changes are designed to be compatible with existing software. - The existing support for IPv4 addresses is retained. Transition - issues related to the co-existence of both IPv4 and IPv6 addresses in - the DNS are discussed in [4]. - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - This document combines RFC 1886 [5] and changes to RFC 1886 made by - RFC 3152 [6], obsoleting both. Changes mainly consist in replacing - the IP6.INT domain by IP6.ARPA as defined in RFC 3152. - -2. New resource record definition and domain - - A record type is defined to store a host's IPv6 address. A host that - has more than one IPv6 address must have more than one such record. - - - - - - - -Thomson, et al. Standards Track [Page 2] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -2.1 AAAA record type - - The AAAA resource record type is a record specific to the Internet - class that stores a single IPv6 address. - - The IANA assigned value of the type is 28 (decimal). - -2.2 AAAA data format - - A 128 bit IPv6 address is encoded in the data portion of an AAAA - resource record in network byte order (high-order byte first). - -2.3 AAAA query - - An AAAA query for a specified domain name in the Internet class - returns all associated AAAA resource records in the answer section of - a response. - - A type AAAA query does not trigger additional section processing. - -2.4 Textual format of AAAA records - - The textual representation of the data portion of the AAAA resource - record used in a master database file is the textual representation - of an IPv6 address as defined in [3]. - -2.5 IP6.ARPA Domain - - A special domain is defined to look up a record given an IPv6 - address. The intent of this domain is to provide a way of mapping an - IPv6 address to a host name, although it may be used for other - purposes as well. The domain is rooted at IP6.ARPA. - - An IPv6 address is represented as a name in the IP6.ARPA domain by a - sequence of nibbles separated by dots with the suffix ".IP6.ARPA". - The sequence of nibbles is encoded in reverse order, i.e., the - low-order nibble is encoded first, followed by the next low-order - nibble and so on. Each nibble is represented by a hexadecimal digit. - For example, the reverse lookup domain name corresponding to the - address - - 4321:0:1:2:3:4:567:89ab - - would be - - b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. - ARPA. - - - - -Thomson, et al. Standards Track [Page 3] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -3. Modifications to existing query types - - All existing query types that perform type A additional section - processing, i.e., name server (NS), location of services (SRV) and - mail exchange (MX) query types, must be redefined to perform both - type A and type AAAA additional section processing. These - definitions mean that a name server must add any relevant IPv4 - addresses and any relevant IPv6 addresses available locally to the - additional section of a response when processing any one of the above - queries. - -4. Security Considerations - - Any information obtained from the DNS must be regarded as unsafe - unless techniques specified in [7] or [8] are used. The definitions - of the AAAA record type and of the IP6.ARPA domain do not change the - model for use of these techniques. - - So, this specification is not believed to cause any new security - problems, nor to solve any existing ones. - -5. IANA Considerations - - There are no IANA assignments to be performed. - -6. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - -Thomson, et al. Standards Track [Page 4] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Acknowledgments - - Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien - Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin - (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic - Roudaut (IRISA) and G6 group for their help during the RFC 1886 - Interop tests sessions. - - Many thanks to Alain Durand and Olafur Gudmundsson for their support. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Thomson, et al. Standards Track [Page 5] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Appendix A: Changes from RFC 1886 - - The following changes were made from RFC 1886 "DNS Extensions to - support IP version 6": - - - Replaced the "IP6.INT" domain by "IP6.ARPA". - - Mentioned SRV query types in section 3 "MODIFICATIONS TO - EXISTING QUERY TYPES" - - Added security considerations. - - Updated references : - * From RFC 1884 to RFC 3513 (IP Version 6 Addressing - Architecture). - * From "work in progress" to RFC 2893 (Transition Mechanisms for - IPv6 Hosts and Routers). - * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. - - Updated document abstract - - Added table of contents - - Added full copyright statement - - Added IANA considerations section - - Added Intellectual Property Statement - -Normative References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - -Informative References - - [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 - Hosts and Routers", RFC 2893, August 2000. - - [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August - 2001. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999 - - - - - - -Thomson, et al. Standards Track [Page 6] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - - [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - -Authors' Addresses - - Susan Thomson - Cisco Systems - 499 Thornall Street, 8th floor - Edison, NJ 08837 - - Phone: +1 732-635-3086 - EMail: sethomso@cisco.com - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - - EMail: huitema@microsoft.com - - - Vladimir Ksinant - 6WIND S.A. - Immeuble Central Gare - Bat.C - 1, place Charles de Gaulle - 78180, Montigny-Le-Bretonneux - France - - Phone: +33 1 39 30 92 36 - EMail: vladimir.ksinant@6wind.com - - - Mohsen Souissi - AFNIC - Immeuble International - 2, rue Stephenson, - 78181, Saint-Quentin en Yvelines Cedex - France - - Phone: +33 1 39 30 83 40 - EMail: Mohsen.Souissi@nic.fr - - - - - - - - - - -Thomson, et al. Standards Track [Page 7] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Thomson, et al. Standards Track [Page 8] - + + + + + + +Network Working Group S. Thomson +Request for Comments: 3596 Cisco +Obsoletes: 3152, 1886 C. Huitema +Category: Standards Track Microsoft + V. Ksinant + 6WIND + M. Souissi + AFNIC + October 2003 + + + DNS Extensions to Support IP Version 6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines the changes that need to be made to the Domain + Name System (DNS) to support hosts running IP version 6 (IPv6). The + changes include a resource record type to store an IPv6 address, a + domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. New resource record definition and domain. . . . . . . . . . . 2 + 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 + 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 + 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 + 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 + 3. Modifications to existing query types. . . . . . . . . . . . . 4 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 + + + +Thomson, et al. Standards Track [Page 1] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 + Informative References . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + Current support for the storage of Internet addresses in the Domain + Name System (DNS) [1,2] cannot easily be extended to support IPv6 + addresses [3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses in the DNS, this document + defines the following extensions: + + o A resource record type is defined to map a domain name to an + IPv6 address. + + o A domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. + The existing support for IPv4 addresses is retained. Transition + issues related to the co-existence of both IPv4 and IPv6 addresses in + the DNS are discussed in [4]. + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + This document combines RFC 1886 [5] and changes to RFC 1886 made by + RFC 3152 [6], obsoleting both. Changes mainly consist in replacing + the IP6.INT domain by IP6.ARPA as defined in RFC 3152. + +2. New resource record definition and domain + + A record type is defined to store a host's IPv6 address. A host that + has more than one IPv6 address must have more than one such record. + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +2.1 AAAA record type + + The AAAA resource record type is a record specific to the Internet + class that stores a single IPv6 address. + + The IANA assigned value of the type is 28 (decimal). + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not trigger additional section processing. + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of an IPv6 address as defined in [3]. + +2.5 IP6.ARPA Domain + + A special domain is defined to look up a record given an IPv6 + address. The intent of this domain is to provide a way of mapping an + IPv6 address to a host name, although it may be used for other + purposes as well. The domain is rooted at IP6.ARPA. + + An IPv6 address is represented as a name in the IP6.ARPA domain by a + sequence of nibbles separated by dots with the suffix ".IP6.ARPA". + The sequence of nibbles is encoded in reverse order, i.e., the + low-order nibble is encoded first, followed by the next low-order + nibble and so on. Each nibble is represented by a hexadecimal digit. + For example, the reverse lookup domain name corresponding to the + address + + 4321:0:1:2:3:4:567:89ab + + would be + + b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. + ARPA. + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +3. Modifications to existing query types + + All existing query types that perform type A additional section + processing, i.e., name server (NS), location of services (SRV) and + mail exchange (MX) query types, must be redefined to perform both + type A and type AAAA additional section processing. These + definitions mean that a name server must add any relevant IPv4 + addresses and any relevant IPv6 addresses available locally to the + additional section of a response when processing any one of the above + queries. + +4. Security Considerations + + Any information obtained from the DNS must be regarded as unsafe + unless techniques specified in [7] or [8] are used. The definitions + of the AAAA record type and of the IP6.ARPA domain do not change the + model for use of these techniques. + + So, this specification is not believed to cause any new security + problems, nor to solve any existing ones. + +5. IANA Considerations + + There are no IANA assignments to be performed. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + +Thomson, et al. Standards Track [Page 4] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Acknowledgments + + Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien + Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin + (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic + Roudaut (IRISA) and G6 group for their help during the RFC 1886 + Interop tests sessions. + + Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 5] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Appendix A: Changes from RFC 1886 + + The following changes were made from RFC 1886 "DNS Extensions to + support IP version 6": + + - Replaced the "IP6.INT" domain by "IP6.ARPA". + - Mentioned SRV query types in section 3 "MODIFICATIONS TO + EXISTING QUERY TYPES" + - Added security considerations. + - Updated references : + * From RFC 1884 to RFC 3513 (IP Version 6 Addressing + Architecture). + * From "work in progress" to RFC 2893 (Transition Mechanisms for + IPv6 Hosts and Routers). + * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. + - Updated document abstract + - Added table of contents + - Added full copyright statement + - Added IANA considerations section + - Added Intellectual Property Statement + +Normative References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + +Informative References + + [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + + + + + +Thomson, et al. Standards Track [Page 6] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +Authors' Addresses + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + + Phone: +1 732-635-3086 + EMail: sethomso@cisco.com + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + Vladimir Ksinant + 6WIND S.A. + Immeuble Central Gare - Bat.C + 1, place Charles de Gaulle + 78180, Montigny-Le-Bretonneux - France + + Phone: +33 1 39 30 92 36 + EMail: vladimir.ksinant@6wind.com + + + Mohsen Souissi + AFNIC + Immeuble International + 2, rue Stephenson, + 78181, Saint-Quentin en Yvelines Cedex - France + + Phone: +33 1 39 30 83 40 + EMail: Mohsen.Souissi@nic.fr + + + + + + + + + + +Thomson, et al. Standards Track [Page 7] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 8] +