--- 1/draft-ietf-ipv6-scoping-arch-01.txt 2006-02-05 00:03:57.000000000 +0100 +++ 2/draft-ietf-ipv6-scoping-arch-02.txt 2006-02-05 00:03:57.000000000 +0100 @@ -1,60 +1,93 @@ IETF IPv6 Working Group S. Deering Internet-Draft Cisco Systems -Expires: August 13, 2004 B. Haberman - Caspian Networks +Expires: February 18, 2005 B. Haberman + Johns Hopkins Univ T. Jinmei Toshiba E. Nordmark Sun Microsystems B. Zill Microsoft - February 13, 2004 + August 20, 2004 IPv6 Scoped Address Architecture - draft-ietf-ipv6-scoping-arch-01.txt + draft-ietf-ipv6-scoping-arch-02.txt Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 13, 2004. + This Internet-Draft will expire on February 18, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids using the syntax and usage of unicast site-local addresses. +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 + 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 + 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 + 11.1 Non-Global Addresses . . . . . . . . . . . . . . . . . . 15 + 11.2 The Part . . . . . . . . . . . . . . . . . . . 15 + 11.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . 17 + 11.5 Related API . . . . . . . . . . . . . . . . . . . . . . 18 + 11.6 Omitting Zone Indices . . . . . . . . . . . . . . . . . 18 + 11.7 Combinations of Delimiter Characters . . . . . . . . . . 18 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 + 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 16.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + 16.2 Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . 23 + 1. Introduction Internet Protocol version 6 includes support for addresses of different "scope", that is, both global and non-global (e.g., link-local) addresses. While non-global addressing has been introduced operationally in the IPv4 Internet, both in the use of private address space ("net 10", etc.) and with administratively scoped multicast addresses, the design of IPv6 formally incorporates the notion of address scope into its base architecture. This document specifies the architectural characteristics, expected @@ -110,30 +143,30 @@ For example, implementations often use the unspecified address to represent "any" address in APIs. In such a case, implementations may want to regard the address in a particular scope to represent the notion of "any addresses in the scope." This document does not prohibit such a usage, as long as it is limited within the implementation. [1] defines IPv6 addresses with embedded IPv4 addresses as part of global addresses. Thus, those addresses have global scope, with regards to the IPv6 scoped address architecture. However, an - implementation may use those addresses as if they had other type of - scopes for convenience. For instance, [6] assigns link-local scope to - IPv4 auto-configured link-local addresses (the addresses from the - prefix 169.254.0.0/16 [7]), and converts those addresses into - IPv4-mapped IPv6 addresses in order to perform destination address - selection among IPv4 and IPv6 addresses. This would implicitly mean - the IPv4-mapped IPv6 addresses equivalent to the IPv4 - auto-configuration link-local addresses have link-local scope. This - document does not preclude such a usage, as long as it is limited - within the implementation. + implementation may use those addresses as if they had other scopes + for convenience. For instance, [6] assigns link-local scope to IPv4 + auto-configured link-local addresses (the addresses from the prefix + 169.254.0.0/16 [7]), and converts those addresses into IPv4-mapped + IPv6 addresses in order to perform destination address selection + among IPv4 and IPv6 addresses. This would implicitly mean the + IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration + link-local addresses have link-local scope. This document does not + preclude such a usage, as long as it is limited within the + implementation. Anycast addresses [1] are allocated from the unicast address space and have the same scope properties as unicast addresses. All statements in this document regarding unicast apply equally to anycast. For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). The interface-local scope spans a single interface only; a multicast address of interface-local scope is useful only for loopback delivery @@ -210,21 +243,24 @@ o Zones of the same scope cannot overlap, i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope, i.e., a smaller scope zone cannot include more topology than any larger scope zone with which it shares any links or interfaces. o Each zone is required to be "convex" from a routing perspective, i.e., packets sent from one interface to any other interface in - the same zone are never routed outside the zone. + the same zone are never routed outside the zone. Note, however, + that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 + tunnel link [8]), a lower layer network of the tunnel can be + located outside the zone without breaking the convexity property. Each interface belongs to exactly one zone of each possible scope. Note that this means an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface. 6. Zone Indices Considering the fact that the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local @@ -272,44 +308,48 @@ A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [8], presumably established over either the Ethernet or the point-to-point link.) It is thus attached to five interface-local zones, identified by the interface indices 1 through 5. Because the two Ethernet interfaces are attached to the same link, the node is attached to only four link-local zones, identified by - link indices 1 through 4. + link indices 1 through 4. Also note that even if the tunnel + interface is established over the Ethernet, the tunnel link gets its + own link index, which is different from the index of the Ethernet + link zone. - Each zone index of a particular scope should contain an information - to represent the scope type, so that all indices of all scopes are - unique within the node and zone indices themselves can be used for a - dedicated purpose. An entry of a Management Information Base (MIB) - will be an example of the dedicated purpose. The actual - representation to encode the scope type is implementation dependent - and is out of scope of this document. Within this document, indices - are simply represented like "link index 2" for readability. + Each zone index of a particular scope should contain enough + information to allow the determination of the scope, so that all + indices of all scopes are unique within the node and zone indices + themselves can be used for a dedicated purpose. Usage of the index + to identify an entry in the Management Information Base (MIB) is an + example of the dedicated purpose. The actual representation to + encode the scope is implementation dependent and is out of scope of + this document. Within this document, indices are simply represented + like "link index 2" for readability. The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well be using entirely different interface and link index values for that link. An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each - scope SHOULD be reserved to mean "use the default zone". Unlike other - zone indices, the default ID does not contain any scope type, and the - scope type is determined by the address by which the default ID was - accompanied. An implementation may additionally define a separate - default zone for each scope type. Those default indices can also be - used as the zone qualifier for an address for which the node is - attached to only one zone, e.g., when using global addresses. + scope SHOULD be reserved to mean "use the default zone". Unlike + other zone indices, the default index does not contain any scope, and + the scope is determined by the address which the default index + accompanies. An implementation may additionally define a separate + default zone for each scope. Those default indices can also be used + as the zone qualifier for an address for which the node is attached + to only one zone, e.g., when using global addresses. There is at present no way for a node to automatically determine which of its interfaces belong to the same zones, e.g., the same link or the same multicast scope zone larger than interface. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid the need to perform manual configuration in most cases, an implementation should, by default, initially assign zone indices as follows, and only as follows: @@ -346,21 +386,21 @@ link) link Figure 2: Example of Default Zone Indices As well as initially assigning zone indices, as specified above, an implementation should automatically select a default zone for each scope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index of zero). For instance, in the example shown in Figure 2, the implementation might automatically select intf2 and link2 as the - default zones for each of those three scopes. (Perhaps the selection + default zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interface other than the loopback interface as the default for each scope.) A means must also be provided for manually assigning the default zone for a scope, overriding any automatic assignment. Because the unicast loopback address, ::1, may not be assigned to any interface other than the loopback interface, it is recommended that, whenever ::1 is specified without a zone index, or with the default zone index, it be interpreted as belonging to the loopback link-local zone, regardless of which link-local zone has been selected as the @@ -408,29 +448,29 @@ --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link Figure 3: Complete Zone Indices Example - Although the examples above show the zones being assigned index + Although the above examples show the zones being assigned index values sequentially for each scope, starting at one, the zone index values are arbitrary. An implementation may use any value it chooses to label a zone as long as it meets the requirement that the index value of each zone of all scopes be unique within the node and that zero SHOULD be reserved to represent the default zone. Implementations choosing to follow the recommended basic API [10] will want to restrict their index values to those that can be - represented by the sin6_scope_id field of a sockaddr_in6 structure. + represented by the sin6_scope_id field of the sockaddr_in6 structure. 7. Sending Packets When an upper-layer protocol sends a packet to a non-global destination address, it must have a means of identifying to the IPv6 layer the intended zone, for cases in which the node is attached to more than one zone of the destination address's scope. Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no @@ -457,30 +497,30 @@ 9. Forwarding When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows: o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a - (conceptual) routing table specific to that zone. That routing - table is restricted to refer only to interfaces belonging to that - zone. + (conceptual) routing table specific to that zone (see Section 10). + That routing table is restricted to refer only to interfaces + belonging to that zone. o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address - and arrival interface of the packet. If transmitting the packet on - the chosen next-hop interface would cause the packet to leave the - zone of the source address, i.e., cross a zone boundary of the + and arrival interface of the packet. If transmitting the packet + on the chosen next-hop interface would cause the packet to leave + the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note: Code 2 is currently left as unassigned in [4]. But the IANA is going to re-assign the value for the new purpose, and [4] will be revised with this change. Note that even with the decision that unicast site-local addresses are deprecated, the above procedure still applies to link-local @@ -513,50 +553,50 @@ This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link- local then the receiving node can know that the packet originated on- link. As a result, this will help the receiving node send a "response" packet with the final destination of the received packet as the source address without breaking its source zone. Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated - zone boundary in the previously-used next address field. For example, - consider a case where a link-border node (e.g., a router) receives a - packet with the destination being a link-local address, and the - source address a global address. If the packet contains a Routing - Header where the next address is a global address, the next-hop - interface to the global address may belong to a different link than - that of the original destination. This is allowed, because the scope - of the next address is not smaller than the scope of the original - destination. + zone boundary in the previously-used next address field. For + example, consider a case where a link-border node (e.g., a router) + receives a packet with the destination being a link-local address, + and the source address a global address. If the packet contains a + Routing Header where the next address is a global address, the + next-hop interface to the global address may belong to a different + link than that of the original destination. This is allowed, because + the scope of the next address is not smaller than the scope of the + original destination. 10. Routing Note: since unicast site-local addresses are deprecated, and link-local addresses do not need routing, the discussion in this section only applies to multicast scoped routing. When a routing protocol determines that it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra- zone connectivity. In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global groups as well as for all of the scoped groups for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for each specific zone. To protect inter-zone integrity, routers must be selective in the group information that is shared with neighboring routers. Routers - routinely exchange routing information with neighboring routers. When - a router is transmitting this routing information, it must not + routinely exchange routing information with neighboring routers. + When a router is transmitting this routing information, it must not include any information about zones other than the zones assigned to the interface used to transmit the information. * * * * * =========== Organization X * * | | * * | | * +-*----|-------|------+ * | * intf1 intf2 | * @@ -615,117 +645,120 @@ zone. 11. Textual Representation As already mentioned, to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well. As a common notation to specify the scope zone, an implementation SHOULD support the following format.
% + where
is a literal IPv6 address, is a string to identify the zone of the address, and - `%' is a delimeter character to distinguish between
and + `%' is a delimiter character to distinguish between
and . - The following subsections describe detail definitions, concrete + The following subsections describe detailed definitions, concrete examples, and additional notes of the format. 11.1 Non-Global Addresses The format applies to all kinds of unicast and multicast addresses of non-global scope except the unspecified address, which does not have a scope. The format is meaningless and should not be used for global addresses. The loopback address belongs to the trivial link, i.e., - the link attached to the loopback interface, thus the format should - not be used for the loopback address either. This document does not - specify the usage of the format when the
is the unspecified - address, since the address does not have a scope. This document, - however, does not prohibit an implementation from using the format - for those special addresses for implementation dependent purposes. + the link attached to the loopback interface, and thus the format + should not be used for the loopback address either. This document + does not specify the usage of the format when the
is the + unspecified address, since the address does not have a scope. This + document, however, does not prohibit an implementation from using the + format for those special addresses for implementation dependent + purposes. -11.2 Zone Indices +11.2 The Part In the textual representation, the part should be able to identify a particular zone of the address's scope. Although a zone - index is expected to contain the scope type and to be unique among - all scopes as described in Section 6 of this document, the - part of this format does not have to contain the scope type because - the
part should specify the appropriate scope. This also - means the part does not have to be unique among all scopes. + index is expected to contain enough information to determine the + scope and to be unique among all scopes as described in Section 6 of + this document, the part of this format does not have to + contain the scope because the
part should specify the + appropriate scope. This also means the part does not have + to be unique among all scopes. - With this loosened property, an implementation can use convenient + With this loosened property, an implementation can use a convenient representation as . For example, to represent link index 2, the implementation can simply use "2" as , which would be - more readable than other representation that contains the scope type - "link". + more readable than other representations that contain the "link" + scope. When an implementation interprets the format, it should construct the - "full" zone ID, which contains the scope type, from the - part and the scope type specified by the
part. (Remember - that a zone index itself should contain the scope type as specified - in Section 6.) + "full" zone index, which contains the scope, from the part + and the scope specified by the
part. (Remember that a zone + index itself should contain the scope as specified in Section 6.) An implementation SHOULD support at least numerical indices as , which are non-negative decimal integers. The default zone - ID, which should typically be 0 (see Section 6), is included in the - integers. When is the default, the delimiter character, - "%", and can be omitted. Similarly, if a textual - representation of an IPv6 address is given without a zone ID, it - should be interpreted as
% where is - the default zone ID of the scope that
has. + index, which should typically be 0 (see Section 6), is included in + the integers. When is the default, the delimiter + character, "%", and can be omitted. Similarly, if a + textual representation of an IPv6 address is given without a zone + index, it should be interpreted as
% where + is the default zone index of the scope that
+ has. An implementation MAY support other kinds of non-null strings as . However, the strings must not conflict with the delimiter character. The precise format and semantics of such additional strings is implementation dependent. One possible candidate of such strings would be interface names, - since interfaces uniquely disambiguate any type of scopes. In - particular, interface names can be used as "default identifiers" for - interfaces and links, because there is, by default, a one-to-one - mapping between interfaces and each of those scopes as described in - Section 6. + since interfaces uniquely disambiguate any scopes. In particular, + interface names can be used as "default identifiers" for interfaces + and links, because there is, by default, a one-to-one mapping between + interfaces and each of those scopes as described in Section 6. An implementation could also use interface names as for larger scopes than links, but there might be some confusion in such - use. For example, when more than one interface belongs to a same + use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name - would encounter a same kind of problem, when it prints an address + would encounter the same kind of problem, when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent. - It cannot be assumed that a same index is common to all nodes in a + It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a - node and MUST NOT be sent on a wire unless every node that interprets - the format agrees on the semantics. + node and MUST NOT be sent on the wire unless every node that + interprets the format agrees on the semantics. 11.3 Examples Here are examples. The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th organization of the node) would be represented as follows: fe80::1234%1 ff02::5678%5 ff08::9abc%10 - (Here we assume a natual translation from a zone index to the + + (Here we assume a natural translation from a zone index to the part where the Nth zone of any scope is translated into "N".) If we use interface names as , those addresses could also be represented as follows: fe80::1234%ne0 ff02::5678%pvc1.3 ff08::9abc%interface10 @@ -759,35 +792,36 @@ Note that we cannot just type like % telnet fe80::2 here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to use for connecting. Instead, we should type the link-local address with the link index as follows: % telnet fe80::2%3 - where "3" after the delimiter character `%' conrresponds to the link + + where "3" after the delimiter character `%' corresponds to the link index of the point-to-point link. 11.5 Related API An extension to the recommended basic API defines how the format for non-global addresses should be treated in library functions that translate a nodename to an address, or vice versa [11]. 11.6 Omitting Zone Indices The format defined in this document does not intend to invalidate the original format for non-global addresses, that is, the format without the zone index portion. As described in Section 6, in some common - cases with the notion of the default zone ID, there can be no + cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the "%" part, and, as a result, it can act as if it did not support the extended format at all. 11.7 Combinations of Delimiter Characters There are other kinds of delimiter characters defined for IPv6 addresses. In this subsection, we describe how they should be combined with the format for non-global addresses. @@ -791,132 +825,145 @@ addresses. In this subsection, we describe how they should be combined with the format for non-global addresses. The IPv6 addressing architecture [1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the 2nd link can be represented as follows: fe80::%2/64 - In this combination, it is important to place the zone index portion before the prefix length, when we consider parsing the format by a - name-to-address library function [11]. That is, we can first separate - the address with the zone index from the prefix length, and just pass - the former to the library function. + name-to-address library function [11]. That is, we can first + separate the address with the zone index from the prefix length, and + just pass the former to the library function. The preferred format for literal IPv6 addresses in URL's are also defined [12]. When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format. - However, the typed URL is often sent on a wire, and it would cause + However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the portion of the address. Also, the format for non-global addresses might conflict with the URI syntax [13], since the syntax defines the delimiter character (`%') as the escape character. Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. As for the conflict issue with the URI format, it would be better to wait until the relationship between the preferred format and the URI syntax is clarified. In fact, the preferred - format for IPv6 literal addresses itself has same kind of conflict. - In any case, it is recommended to use an FQDN instead of a literal - IPv6 address in a URL, whenever an FQDN is available. + format for IPv6 literal addresses itself has the same kind of + conflict. In any case, it is recommended to use an FQDN instead of a + literal IPv6 address in a URL, whenever an FQDN is available. 12. Security Considerations + A limited scoped address without its zone index has security + implications, and cannot be used for some security contexts. For + example, a link-local address cannot be used in a traffic selector of + a security association established by Internet Key Exchange (IKE) + when the IKE messages are carried over global addresses. Also, a + link-local address without its zone index cannot be used in access + control lists. + The routing section of this document specifies a set of guidelines that allow routers to prevent zone-specific information from leaking out of each zone. If, for example, multicast site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Since the use of the textual representation of non-global addresses - is restricted within a single node, it does not create a security - vulnerability from outside the node. However, a malicious node might - send a packet that contains a textual IPv6 non-global address with a - zone index, intending to deceive the receiving node about the zone of - the non-global address. Thus, an implementation should be careful - when it receives packets that contain textual non-global addresses as - data. + is restricted to use within a single node, it does not create a + security vulnerability from outside the node. However, a malicious + node might send a packet that contains a textual IPv6 non-global + address with a zone index, intending to deceive the receiving node + about the zone of the non-global address. Thus, an implementation + should be careful when it receives packets that contain textual + non-global addresses as data. -13. Contributors +13. IANA Considerations + + This document has no actions for IANA. + +14. Contributors This document is a combination of several separate efforts. Atsushi Onoe took a significant role in one of them, and deeply contributed to the content of Section 11 as a co-author of a separate proposal. -14. Acknowledgements +15. Acknowledgements - Many members the IPv6 working group provided useful comments and + Many members of the IPv6 working group provided useful comments and feedback on this document. In particular, Margaret Wasserman and Bob Hinden led the working group to make a consensus on IPv6 local addressing. Richard Draves proposed an additional rule to process Routing header containing scoped addresses. Dave Thaler and Francis Dupont gave valuable suggestions to define semantics of zone indices in terms of related API. Pekka Savola reviewed a draft of the document very carefully, and made detailed comments including serious - problems. + problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy + Gleeson reviewed and helped improve the document during the + preparation for publication. -Normative References +16. References + +16.1 Normative References [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, BCP 14, March 1999. + Levels", BCP 14, RFC 2119, March 1997. - [3] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) + [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. - [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for - the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, - December 1998. + [4] Conta, A. and S. Deering, "Internet Control Message Protocol + (ICMPv6) for the Internet Protocol Version 6 (IPv6) + Specification", RFC 2463, December 1998. -Informative References +16.2 Informative References [5] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-02.txt (work - in progress), November 2003. + Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work in + progress), March 2004. [6] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. - [7] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of Link-Local IPv4 Addresses", - draft-ietf-zeroconf-ipv4-linklocal-12.txt (work in progress), - January 2004. + [7] Aboba, B., "Dynamic Configuration of Link-Local IPv4 + Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in + progress), July 2004. - [8] Conta, A., "Generic Packet Tunneling in IPv6 Specification", - RFC 2473, December 1998. + [8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 + Specification", RFC 2473, December 1998. - [9] Narten, T., "Neighbor Discovery for IP Version 6 (IPv6)", RFC - 2461, December 1998. + [9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. [10] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. - [11] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. - Stevens, "Scoped Address Extensions to the IPv6 Basic Socket - API", Internet-Draft