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