| < draft-ietf-ipv6-addr-arch-v4-03.txt | draft-ietf-ipv6-addr-arch-v4-04.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT R. Hinden, Nokia | INTERNET-DRAFT R. Hinden, Nokia | |||
| April 29, 2005 S. Deering, Cisco Systems | May 20, 2005 S. Deering, Cisco Systems | |||
| Obsoletes: RFC3513 | ||||
| IP Version 6 Addressing Architecture | IP Version 6 Addressing Architecture | |||
| <draft-ietf-ipv6-addr-arch-v4-03.txt> | <draft-ietf-ipv6-addr-arch-v4-04.txt> | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 34 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet Draft expires November 3, 2005. | This Internet Draft expires November 25, 2005. | |||
| Abstract | Abstract | |||
| This specification defines the addressing architecture of the IP | This specification defines the addressing architecture of the IP | |||
| Version 6 protocol [IPV6]. The document includes the IPv6 addressing | Version 6 protocol. The document includes the IPv6 addressing model, | |||
| model, text representations of IPv6 addresses, definition of IPv6 | text representations of IPv6 addresses, definition of IPv6 unicast | |||
| unicast addresses, anycast addresses, and multicast addresses, and an | addresses, anycast addresses, and multicast addresses, and an IPv6 | |||
| IPv6 node's required addresses. | node's required addresses. | |||
| This document obsoletes RFC-3513 "IP Version 6 Addressing | This document obsoletes RFC-3513 "IP Version 6 Addressing | |||
| Architecture". | Architecture". | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction.................................................3 | 1. Introduction.................................................3 | |||
| 2. IPv6 Addressing..............................................3 | 2. IPv6 Addressing..............................................3 | |||
| 2.1 Addressing Model.........................................4 | 2.1 Addressing Model.........................................4 | |||
| skipping to change at page 8, line 28 ¶ | skipping to change at page 8, line 28 ¶ | |||
| +-------------------------------+---------------------------------+ | +-------------------------------+---------------------------------+ | |||
| Though a very simple router may have no knowledge of the internal | Though a very simple router may have no knowledge of the internal | |||
| structure of IPv6 unicast addresses, routers will more generally have | structure of IPv6 unicast addresses, routers will more generally have | |||
| knowledge of one or more of the hierarchical boundaries for the | knowledge of one or more of the hierarchical boundaries for the | |||
| operation of routing protocols. The known boundaries will differ | operation of routing protocols. The known boundaries will differ | |||
| from router to router, depending on what positions the router holds | from router to router, depending on what positions the router holds | |||
| in the routing hierarchy. | in the routing hierarchy. | |||
| Except for the knowledge of the subnet boundary discussed in the | Except for the knowledge of the subnet boundary discussed in the | |||
| pervious paragraphs nodes should not make any assumptions about the | previous paragraphs nodes should not make any assumptions about the | |||
| structure of an IPv6 address. | structure of an IPv6 address. | |||
| 2.5.1 Interface Identifiers | 2.5.1 Interface Identifiers | |||
| Interface identifiers in IPv6 unicast addresses are used to identify | Interface identifiers in IPv6 unicast addresses are used to identify | |||
| interfaces on a link. They are required to be unique within a subnet | interfaces on a link. They are required to be unique within a subnet | |||
| prefix. It is recommended that the same interface identifier not be | prefix. It is recommended that the same interface identifier not be | |||
| assigned to different nodes on a link. They may also be unique over | 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 | a broader scope. In some cases an interface's identifier will be | |||
| derived directly from that interface's link-layer address. The same | derived directly from that interface's link-layer address. The same | |||
| skipping to change at page 14, line 36 ¶ | skipping to change at page 14, line 36 ¶ | |||
| An IPv6 multicast address is an identifier for a group of interfaces | An IPv6 multicast address is an identifier for a group of interfaces | |||
| (typically on different nodes). An interface may belong to any | (typically on different nodes). An interface may belong to any | |||
| number of multicast groups. Multicast addresses have the following | number of multicast groups. Multicast addresses have the following | |||
| format: | format: | |||
| | 8 | 4 | 4 | 112 bits | | | 8 | 4 | 4 | 112 bits | | |||
| +------ -+----+----+---------------------------------------------+ | +------ -+----+----+---------------------------------------------+ | |||
| |11111111|flgs|scop| group ID | | |11111111|flgs|scop| group ID | | |||
| +--------+----+----+---------------------------------------------+ | +--------+----+----+---------------------------------------------+ | |||
| binary 11111111 at the start of the address identifies the | binary 11111111 at the start of the address identifies the address | |||
| address as being a multicast address. | as being a multicast address. | |||
| +-+-+-+-+ | +-+-+-+-+ | |||
| flgs is a set of 4 flags: |0|0|0|T| | flgs is a set of 4 flags: |0|R|P|T| | |||
| +-+-+-+-+ | +-+-+-+-+ | |||
| The high-order 3 flags are reserved, and must be | The high-order flag is reserved, and must be initialized to 0. | |||
| initialized to 0. | ||||
| T = 0 indicates a permanently-assigned ("well-known") | T = 0 indicates a permanently-assigned ("well-known") multicast | |||
| multicast address, assigned by the Internet Assigned Number | address, assigned by the Internet Assigned Number Authority | |||
| Authority (IANA). | (IANA). | |||
| T = 1 indicates a non-permanently-assigned ("transient") | T = 1 indicates a non-permanently-assigned ("transient" or | |||
| multicast address. | "dynamically" assigned) multicast address. | |||
| scop is a 4-bit multicast scope value used to limit the scope of | The P flag's definition and usage can be found in [RFC3306]. | |||
| the multicast group. The values are: | ||||
| 0 reserved | The R flag's definition and usage can be found in [RFC3956]. | |||
| 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 | scop is a 4-bit multicast scope value used to limit the scope of | |||
| node, and is useful only for loopback transmission of | the multicast group. The values are: | |||
| multicast. | ||||
| link-local multicast scope spans the same | 0 reserved | |||
| topological region as the corresponding unicast scope. | 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 | ||||
| admin-local scope is the smallest scope that must be | interface-local scope spans only a single interface on a | |||
| administratively configured, i.e., not automatically | node, and is useful only for loopback transmission of | |||
| derived from physical connectivity or other, non- | multicast. | |||
| multicast-related configuration. | ||||
| site-local scope is intended to span a single site. | link-local multicast scope spans the same | |||
| topological region as the corresponding unicast scope. | ||||
| organization-local scope is intended to span multiple | admin-local scope is the smallest scope that must be | |||
| sites belonging to a single organization. | administratively configured, i.e., not automatically | |||
| derived from physical connectivity or other, non- | ||||
| multicast-related configuration. | ||||
| scopes labeled "(unassigned)" are available for | site-local scope is intended to span a single site. | |||
| administrators to define additional multicast regions. | ||||
| group ID identifies the multicast group, either permanent or | organization-local scope is intended to span multiple | |||
| transient, within the given scope. | sites belonging to a single organization. | |||
| scopes labeled "(unassigned)" are available for | ||||
| administrators to define additional multicast regions. | ||||
| group ID identifies the multicast group, either permanent or | ||||
| transient, within the given scope. Additional definitions of the | ||||
| multicast group ID field structure is defined in [RFC3306]. | ||||
| The "meaning" of a permanently-assigned multicast address is | The "meaning" of a permanently-assigned multicast address is | |||
| independent of the scope value. For example, if the "NTP servers | independent of the scope value. For example, if the "NTP servers | |||
| group" is assigned a permanent multicast address with a group ID of | group" is assigned a permanent multicast address with a group ID of | |||
| 101 (hex), then: | 101 (hex), then: | |||
| FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface | FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface | |||
| (i.e., the same node) as the sender. | (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 | FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the | |||
| the sender. | sender. | |||
| FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as | FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the | |||
| the sender. | sender. | |||
| FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. | FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. | |||
| Non-permanently-assigned multicast addresses are meaningful only | Non-permanently-assigned multicast addresses are meaningful only | |||
| within a given scope. For example, a group identified by the non- | 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 | 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 | 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 | 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 | with different scope, nor to a permanent group with the same group | |||
| ID. | ID. | |||
| Multicast addresses must not be used as source addresses in IPv6 | Multicast addresses must not be used as source addresses in IPv6 | |||
| skipping to change at page 19, line 8 ¶ | skipping to change at page 19, line 8 ¶ | |||
| 3. Security Considerations | 3. Security Considerations | |||
| IPv6 addressing documents do not have any direct impact on Internet | IPv6 addressing documents do not have any direct impact on Internet | |||
| infrastructure security. Authentication of IPv6 packets is defined | infrastructure security. Authentication of IPv6 packets is defined | |||
| in [AUTH]. | in [AUTH]. | |||
| 4. IANA Considerations | 4. IANA Considerations | |||
| The "IPv4-compatible IPv6 address" is deprecated by this document. | The "IPv4-compatible IPv6 address" is deprecated by this document. | |||
| The IANA should continue to list the address block containing this | The IANA should continue to list the address block containing these | |||
| address as "Reserved by IETF" and not reassign it for any other | addresses at http://www.iana.org/assignments/ipv6-address-space as | |||
| purpose. | "Reserved by IETF" and not reassign it for any other purpose. For | |||
| example: | ||||
| The IANA should update the references for the IPv6 Address | 0000::/8 Reserved by IETF [RFC3513] [1] | |||
| The IANA is requested to add the following note and link it to this | ||||
| address block. | ||||
| [5] 0000::/96 was previously defined as the "IPv4-compatible IPv6 | ||||
| address" prefix. This definition has been deprecated by | ||||
| [RFC-ietf-ipv6-addr-arch-v4-04.txt]. | ||||
| The IANA is requested to update the references for the IPv6 Address | ||||
| Architecture in the IANA registries to this RFC when it is published. | Architecture in the IANA registries to this RFC when it is published. | |||
| 5. References | 5. References | |||
| 5.1 Normative References | 5.1 Normative References | |||
| [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", RFC2460, December 1998. | (IPv6) Specification", RFC2460, December 1998. | |||
| [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
| 3", RFC2026, BCP00009, October 1996. | 3", RFC2026, BCP00009, October 1996. | |||
| 5.2 Non-Normative References | 5.2 Non-Normative References | |||
| [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host | ||||
| Anycasting Service", RFC1546, November 1993. | ||||
| [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", | [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", | |||
| RFC2402, November 1998. | RFC2402, November 1998. | |||
| [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless | [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless | |||
| Inter-Domain Routing (CIDR): An Address Assignment and | Inter-Domain Routing (CIDR): An Address Assignment and | |||
| Aggregation Strategy", RFC1519, September 1993. | Aggregation Strategy", RFC1519, September 1993. | |||
| [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet | [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet | |||
| Networks", RFC2464, December 1998. | Networks", RFC2464, December 1998. | |||
| [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) | [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) | |||
| Registration Authority", | Registration Authority", | |||
| http://standards.ieee.org/regauth/oui/tutorials/EUI64.html | http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, | |||
| , March 1997. | March 1997. | |||
| [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI | [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI | |||
| Networks", RFC2467, December 1998. | Networks", RFC2467, December 1998. | |||
| [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global | [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global | |||
| Unicast Address Format", RFC3587, August 2003. | Unicast Address Format", RFC3587, August 2003. | |||
| [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, | ||||
| July 1998. | ||||
| [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless | [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless | |||
| Address Autoconfiguration in IPv6", RFC3041, January 2001. | Address Autoconfiguration in IPv6", RFC3041, January 2001. | |||
| [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 | ||||
| Multicast Addresses", RFC 3306, August 2002. | ||||
| [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point | ||||
| (RP) Address in an IPv6 Multicast Address", RFC 3956, | ||||
| November 2004. | ||||
| [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 | [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 | |||
| Transition", RFC4038, March 2005. | Transition", RFC4038, March 2005. | |||
| [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local | [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local | |||
| Addresses", RFC3879, September 2004. | Addresses", RFC3879, September 2004. | |||
| [TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of | ||||
| IPv6 Packets over Token Ring Networks", RFC2470, December | ||||
| 1998. | ||||
| [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for | ||||
| IPv6 Hosts and Routers", RFC2893, August 2000. | ||||
| 6. Author's Addresses | 6. Author's Addresses | |||
| Robert M. Hinden | Robert M. Hinden | |||
| Nokia | Nokia | |||
| 313 Fairchild Drive | 313 Fairchild Drive | |||
| Mountain View, CA 94043 | Mountain View, CA 94043 | |||
| USA | USA | |||
| phone: +1 650 625-2004 | phone: +1 650 625-2004 | |||
| email: bob.hinden@nokia.com | email: bob.hinden@nokia.com | |||
| skipping to change at page 25, line 46 ¶ | skipping to change at page 25, line 46 ¶ | |||
| Addresses" to RFC3587. | Addresses" to RFC3587. | |||
| o Removed mention of NSAP addresses in examples. | o Removed mention of NSAP addresses in examples. | |||
| o Clarified that the "x" in the textual representation can be one to | o Clarified that the "x" in the textual representation can be one to | |||
| four digits. | four digits. | |||
| o Deprecated the "IPv6 Compatible Address" because it is not being | o Deprecated the "IPv6 Compatible Address" because it is not being | |||
| used in the IPv6 transition mechanisms. | used in the IPv6 transition mechanisms. | |||
| o Added the "R" and "P" flags to Section 2.7 on Multicast addresses, | ||||
| and pointers to the documents that define them. | ||||
| o Editorial changes. | o Editorial changes. | |||
| End of changes. 31 change blocks. | ||||
| 80 lines changed or deleted | 92 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||