INTAREA WG S. Chakrabarti Internet-Draft Ericsson Updates: 4861 (if approved) E. Nordmark Intended status: Standards Track Cisco Systems Expires: January 3, 2012 July 2, 2011 Energy Aware IPv6 Neighbor Discovery Optimizations draft-chakrabarti-nordmark-energy-aware-nd-00 Abstract IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless and machine-to-machine communications, there is a desire for extension or optimization of RFC 4861 protocol for more energy- efficient networks and nodes. Research indicates that often networked- nodes require more energy than stand-alone nodes because a node's energy usage depends on network messages it has to receive and or respond. While reducing energy consumption is essential for battery operated nodes in some machines, saving energy actually a cost factor in business in general as the explosion of more device usage is leading to usage of more servers and network infrastructure in all sectors of the society and business. This document describes methods of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and provides a mechanism of built-in prefix-dissemination in simple scenarios. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2012. Copyright Notice Chakrabarti & Nordmark Expires January 3, 2012 [Page 1]
Internet-Draft Energy-aware-nd July 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The New Set Of Requirements . . . . . . . . . . . . . . . . . 5 5. New Neighbor Discovery Options and Messages . . . . . . . . . 5 5.1. Address Registration Option . . . . . . . . . . . . . . . 6 5.2. Authoritative Border Router Option . . . . . . . . . . . . 7 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 7. Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 10 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11 9. The Border Router(BR) Behavior . . . . . . . . . . . . . . . . 11 10. Intermediate-router Behavior . . . . . . . . . . . . . . . . . 12 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Local Mobility . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16.1. Normative References . . . . . . . . . . . . . . . . . . . 13 16.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Chakrabarti & Nordmark Expires January 3, 2012 [Page 2]
Internet-Draft Energy-aware-nd July 2011 1. Introduction IPv6 ND [ND] is based on multicast signaling messages on the local link in order to avoid broadcast messages. Following power-on and initialization of the network in IPv6 Ethernet networks, a node joins the solicited-node multicast address on the interface and then performs duplicate address detection (DAD) for the acquired link- local address by sending a solicited-node multicast message to the link. After that it sends multicast router solicitation (RS) messages to the all-router address to solicit router advertisements. Once the host receives a valid router advertisement (RA) with the "A" flag, it autoconfigures the IPv6 address with the advertised prefix in the router advertisement (RA). Besides this, the IPv6 routers usually send router advertisements periodically on the network. RAs are sent to the all-node multicast address. Nodes send Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve the IPv6 address of the destination on the link. These NS/NA messages are also often multicast messages and it is assumed that the node is on the same link and relies on the fact that the destination node is always powered and generally available. The periodic RA messages in IPv6 ND [ND], and NS/NA messages require all IPv6 nodes in the link to be in listening mode even when they are in idle mode. It requires energy for the sleepy nodes which may be otherwise sleeping during idle mode. Non-sleepy nodes also may save energy if instead of continuous listening mode, they actually pro- actively synchronize their state with one or two entity in the network. With the explosion of Internet-of-things and machine to machine communication, more and more devices would be using IPv6 addresses in the near future. Today, most electricity usage in United States and in developing countries are in the home buildings and commercial buildings; the electronic Internet appliances/tablets etc. are gaining popularities in the modern home networks. These network of nodes must be conscious about saving energy as their number increases as otherwise it will cost more and increase stress on electrical grids, and increases carbon foot-print. IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] addresses many of the concerns described above by optimizing the Router advertisement, minimizing periodic multicast packets in the network and introducing two new options - one for node registration and another for prefix dissemination in a network where all nodes in the network are uniquely identified by their 64-bit Interface Identifier. EUI-64 identifiers are recommended as unique Interface Identifiers, however if the network is isolated from the Internet, uniqueness of the identifiers may be obtained by other mechanisms such as a random number generator with lowest collision rate. Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN Chakrabarti & Nordmark Expires January 3, 2012 [Page 3]
Internet-Draft Energy-aware-nd July 2011 [LOWPAN] network, the concept is mostly applicable to IPv6 network that wants to optimize power. Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize total number of related signaling messages without loosing generality of Neighbor Discovery and autoconfiguration and making host and router communication reliable, is desirable in any IPv6 energy-aware networks such as Home or Enterprise building networks and as well as Data Centers. [ This document is under construction and will have an update soon to solidify the content of the draft] 2. Definition Of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 6LoWPAN-link: It is a wireless link determined by single hop reachability of neighboring nodes. Intermediate-routers: These are the intermediate routers in the home network who can communicate with other intermediate routers in the same home network. These are also the immediate first-hop router for the physically attached hosts or wirelessly reachable hosts. Root-node or Border Rotuer(BR): It is a border router typically located at the junction Internet and Home Network. Host: A host in a IPv6 network is considered a IPv6 node without routing and forwarding capability. EUI-64: It is the IEEE defined 64-bit extended unique identifier formed by concatenation of 24-bit or 36-bit company id value by IEEE Registration Authority and the extension identifier within that company-id assignment. The extension identifiers are 40-bit (for 24-bit company-id) or 28-bit (for the 36-bit company-id) respectively. 3. Assumptions o All nodes in the network carry unique interface ID in order to form the auto-configured IPv6 address uniquely. Chakrabarti & Nordmark Expires January 3, 2012 [Page 4]
Internet-Draft Energy-aware-nd July 2011 o All nodes use the same IPv6 prefix if multi-level prefix distribution technique (described in this document) is used o The special scenario for multi-level prefix dissemination requires a topology where all packets of that network must go through a access-gateway of that network. The access gateway may support multi-level intermediate-rotuers with packet forwarding capability and prefix-distribution capability as discussed in this document. The hosts in this network must send and receive packets through a default router. The default router could be the access-gateway or the Border Router or the intermediate-router depending on the location of the host. 4. The New Set Of Requirements In future homes and new machine-to-machine networks, it will be very often a hierarchical networks of sub-networks which are all directly or indirectly served by a root-node router or gateway with an access to the Internet. In the cloud computing environment, it is possible that part of the network or sub-network are geographically separated. Thus the concept of IPv6-subnet of link-local nodes may be extended. o Node initiated Registration and address allocation in order to avoid periodic multicast messages. o Address allocation through multicast IPv6 Neighbor Discovery [ND] and IPv6 Autoconfiguration [AUTOCONF] with tuned parameters for different sub-networks under one gateway or root home router. For example, one sub-network consists of television and game station networks and another network is a IEE 802.15.4 ZigBee IP network running 6LoWPAN [LOWPAN]. o A Requirement of distribution of configuration securely cascading through the network of sub-networks. o The node registration may replace the requirement of doing Duplicate Address Detection. 5. New Neighbor Discovery Options and Messages This document points to the section of 6LoWPAN-ND [6LOWPAN-ND] as appropriate. 6LoWPAN-ND [6LOWPAN-ND] assumes a concept of 6Lowpan- link which is equivalent to a subnet in classical IPv6-subnet sharing the same IPv6-prefix but it is a collection of sub-networks connected by special routers called 6LR [6LOWPAN-ND]. Chakrabarti & Nordmark Expires January 3, 2012 [Page 5]
Internet-Draft Energy-aware-nd July 2011 5.1. Address Registration Option The Address Registration Option(ARO) is useful for avoiding Duplicate Address Detection messages since it requires a unique ID for registration. The address registration is used for maintaining reachability of the node or host by the router. The routers keep track of host IP addresses that are directly reachable and their corresponding link-layer addresses. This is useful for lossy and lowpower networks and as well as wired networks. An Address Registration Option (ARO) can be included in unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it can be included in the unicast NS messages that a host sends as part of Neighbor Unreachability Detection to determine that it can still reach a default router. The ARO is used by the receiving router to reliably maintain its Neighbor Cache. The same option is included in corresponding Neighbor Advertisement (NA) messages with a Status field indicating the success or failure of the registration. This option is always host initiated. The ARO is required for reliability and power saving. The lifetime field provides flexibility to the host to register an address which should be usable (the reachability information may be propagated to the routing protocols) during its intended sleep schedule of nodes that switches to frequent sleep mode. The sender of the NS also includes the EUI-64 of the interface it is registering an address from. This is used as a unique ID for the detection of duplicate addresses. It is used to tell the difference between the same node re-registering its address and a different node (with a different EUI-64) registering an address that is already in use by someone else. The EUI-64 is also used to deliver an NA carrying an error Status code to the EUI-64 based link-local IPv6 address of the host. When the ARO is used by hosts an SLLA option MUST be included and the address that is to be registered MUST be the IPv6 source address of the Neighbor Solicitation message. Chakrabarti & Nordmark Expires January 3, 2012 [Page 6]
Internet-Draft Energy-aware-nd July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + EUI-64 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: TBD1 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 2. Status: 8-bit unsigned integer. Indicates the status of a registration in the NA response. MUST be set to 0 in NS messages. See below. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Registration Lifetime: 16-bit unsigned integer. The amount of time in a unit of 10 seconds that the router should retain the Neighbor Cache entry for the sender of the NS that includes this option. EUI-64: 64 bits. This field is used to uniquely identify the interface of the registered address by including the EUI-64 identifier assigned to it unmodified. The Status values used in Neighbor Advertisements are: +--------+--------------------------------------------+ | Status | Description | +--------+--------------------------------------------+ | 0 | Success | | 1 | Duplicate Address | | 2 | Neighbor Cache Full | | 3-255 | Allocated using Standards Action [RFC2434] | +--------+--------------------------------------------+ Table 1 5.2. Authoritative Border Router Option This is a special optional operation introducing prefix dissemination for a simple scenario where a network of nodes under the same Border Router (example: Home gateway) share the same prefix. The routers Chakrabarti & Nordmark Expires January 3, 2012 [Page 7]
Internet-Draft Energy-aware-nd July 2011 below the Border Router have limited forwarding/routing capabilities and the packets sent/received by them from the Internet MUST go via the Border Router. This can assume that /64 bit prefix is delegated from the authoritative Border Router node then propagated down through the intermediate nodes to the hosts without change. The intermediate routers should keep a copy of this prefix for local distribution and are responsible for periodic synchronization. |----| | BR | ------ | H7--------------H6 | | iR1 iR2--H1 / \ \ H2 H3 iR3 / \ H4 H5 A typical Topology where ABRO is useful In the above example, we can can think of BR as a Home gateway while iR routers represent intermediate routers which can be considered as in-home smaller routers connecting hosts for different applications or usages such as appliance network or home-entertainment network. The Authoritative Border Router option MUST be included in all Router Advertisement messages when Router Advertisements are used to propagate information between routers in the topology described above. Chakrabarti & Nordmark Expires January 3, 2012 [Page 8]
Internet-Draft Energy-aware-nd July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 3 | Version Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + BR Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: TBD3 Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3. Version Number: 16-bit unsigned integer. The version number corresponding to this set of information contained in the RA message. The authoritative Border router originating the prefix increases this version number each time its set of prefix or context information changes. This version number uses sequence number arithmetic as it may wrap around. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. BR Address: IPv6 address of the Border Router that is the origin of the included version number. This document assumes that an implementation will have configuration knobs to determine whether it is running in classical IPv6 ND [ND] or Optimized Energy Aware ND (this document) mode 6. Applicability Statement This document aims to guide the implementors to choose an appropriate IPv6 neighbor discovery and Address configuration procedures suitable for any IPv6 energy-aware network. These optimization is useful for the classical IPv6 subnet and as well as future home network where the network is composed of several sub-networks served by a root-node or home-gateway and the hosts always send packets through a default- router. Chakrabarti & Nordmark Expires January 3, 2012 [Page 9]
Internet-Draft Energy-aware-nd July 2011 7. Energy-aware Neighbor Discovery Messages 1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only solicited RAs are recommended. An RA MUST contain the Source Link-layer Address option containing Router's link-layer address (this is optional in [ND]. An RA MUST carry Prefix information option with L bit being unset, so that hosts do not multicast any NS messages as part of address resolution. In addition to the Prefix option the RA may carry Authoritative Router option option generated by the root-node. 2. Router Solicitation(RS): Upon system startup, the node sends a multicast or link broadcast (when multicast is not supported at the link-layer) RS to find out the available routers in the link. An RS may be sent at other times as described in section 6.3.7 of RFC 4861. A Router Solicitation MUST carry Source Link-layer Address option. Since no periodic RAs are allowed in a 6LoWPAN network, the host may send periodic unicast messages RS to the routers. The time-periods for the RS varies on the deployment scenarios and the Default Router Lifetime advertised in the RAs. 3. Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND]. 4. Neighbor Solicitation (NS): Neighbor solicitation is used between the hosts and the default-router as part of NUD and registering the host's address(es). An NS message MUST use the Address Registration option in order to accomplish the registration. 5. Neighbor Advertisement (NA): As defined in [ND] 6. Redirect Messages: A router may send a Redirect message to a host. When to send the redirect message is implementation specific; a router may be overloaded or by some means it can determine the proximity of source and destination and decide that they should directly talk to each other. The host behavior is same as described in section 8.3 of RFC 4861[ND], i,e. a host MUST NOT send redirect messages. 7. Message Validation: Same as in RFC 4861[ND] 8. MTU option: As per the RFC 4861. 9. Address Resolution: No NS/NA are sent as the prefixes are treated as off-link. Thus no address resolution is performed at the hosts. The routers keep track of Neighbor Solicitations with Address Registration options(ARO) and create an extended neighbor cache of reachable addresses. The router also knows the nexthop link-local address and corresponding link-layer address when it wants to route a packet. 10. Neighbor Unreachability Detection(NUD): NUD is performed in "forward-progress" fashion as described in section 7.3.1 of RFC 4861[ND]. However, if Address Registration Option is used, the NUD SHOULD be combined with the Re-registration of the node. Chakrabarti & Nordmark Expires January 3, 2012 [Page 10]
Internet-Draft Energy-aware-nd July 2011 This way no extra message for NUD is required. 8. Host Behavior A host sends Router Solicitation at the system startup and also when it suspects that one of its default routers have become unreachable (after NUD fails). A host SHOULD be able to autoconfigure its IPv6 addresses using the IPv6 prefix obtained from Router Advertisement. The host SHOULD form its link-local address from the EUI-64 as specified by IEEE Registration Authority and RFC 2373. If this draft feature is implemented and configured, the host MUST NOT re-direct Neighbor Discovery messages. The host does not require to join solicited-node multicast address but it MUST join the all-node multicast address. A host always sends packets to (one of) its default router(s) unless it receives Router redirect messages from a neighboring router. This is accomplished by the routers never setting the 'L' flag in the Prefix options. The host is unable to forward routes or participate in a routing protocol. 9. The Border Router(BR) Behavior A Border Router normally may have multiple interfaces and connects the nodes in a link like a regular IPv6 subnet(s) or acts as a gateway between separate networks such as Internet and home networks . The Border Router is responsible for distributing one or more /64 prefixes to the nodes to identify a packet belonging to the particular network. The routers SHOULD NOT garbage collect Registered Neighbor Cache entries since they need to retain them until the Registration Lifetime expires. Similarly, if Neighbor Unreachability Detection on the router determines that the host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache entry SHOULD NOT be deleted but be retained until the Registration Lifetime expires. A renewed ARO should mark the cache entry as STALE. When the BR sends a Router Advertisement it SHOULD include a Authoritative Router option that includes its own address. A BR keeps a cache for all the nodes' IP addresses, created from the Address Registration processing. It may send the Router Chakrabarti & Nordmark Expires January 3, 2012 [Page 11]
Internet-Draft Energy-aware-nd July 2011 advertisement with Prefix option and Authoritative Border Router option. 10. Intermediate-router Behavior The intermediate routers may exist in some special scenarios of home networks or other networks where the Border Router sits at the root of the network and all packets go in and out of the gateway. The behavior of this node is still under discussion. But it aids in prefix dissemination or distribution if the Border Router sends the ABRO option with Router Advertisements. The intermediate-router role is somewhat similar to 6LR as defined in [6LOWPAN-ND]. If the intermediate-router acts as a default router to its neighboring hosts, then it should be able to process the Address Registration option and register the neighboring nodes. 11. Bootstrapping If the network is a classic IPv6 subnet, and the energy-aware Neighbor Discovery mechansim is used, then the node uses its link- local address to send Router Solicitation and then it sends the Node Registration message as described in this document in order to form the address. The Duplicate address detection process should be skipped if the network is guaranteed to have unique interface identifiers. The intermerdiate-routers may also first bootstrap as a host and then turn themselves into router-mode. The detail messages will be discussed in the next version of the document. 12. Local Mobility If energy-aware Neighbor Discovery model is used and same IPv6 prefix is shared by all the nodes in the network that is accessed by the Border Router, then it assures transparent mobility of the nodes inside the network bordered by Border Router. The local mobility transparency is quite useful in a home network environment where multiple networks may exist and be served by a Border Router or a Home Gateway. Thus one can wirelessly move a node from one home sub-network to another without disrupting data connection. Chakrabarti & Nordmark Expires January 3, 2012 [Page 12]
Internet-Draft Energy-aware-nd July 2011 13. Security Considerations These optimizations are not known to introduce any new threats against Neighbor Discovery beyond what is already documented for IPv6 [RFC 3756]. However, careful security considerations will be handled in a follow-up IETF publication of this draft. 14. IANA Considerations TBD 15. Acknowledgements The primary idea of this document are from 6LoWPAN Neighbor Discovery document [6LOWPAN-ND] and the discussions from the 6lowpan working group members, chairs Carsten Bormann and Geoff Mulligan and through our discussions with Zach Shelby. The inspiration of such a IPv6 generic document came from Margaret Wasserman who saw a need for such a document at the IOT workshop at Prague IETF. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [6LOWPAN-ND] Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt (work in progress), June 2011. [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6", RFC 4861, September 2007. [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets over IEEE 802.15.4 networks", RFC 4944, September 2007. Chakrabarti & Nordmark Expires January 3, 2012 [Page 13]
Internet-Draft Energy-aware-nd July 2011 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", RFC 4919, August 2007. 16.2. Informative References [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, December 1998. [AUTOCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Autoconfiguration", RFC 4862, September 2007. [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure Neighbor Discovery", RFC 3971, March 2005. [AUTOADHOC] Baccelli, E. and M. Townsley, "IP Addressing Model in Adhoc Networks", draft-ietf-autoconf-adhoc-addr-model-02.txt (work in progress), December 2009. [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , October 2003. [PD] Miwakawya, S., "Requirements for Prefix Delegation", RFC 3769, June 2004. [ULA] "Unique Local IPv6 Addresses", RFC 4193. Authors' Addresses Samita Chakrabarti Ericsson San Jose, CA USA Email: samita.chakrabarti@ericsson.com Erik Nordmark Cisco Systems San Jose, CA USA Email: nordmark@cisco.com Chakrabarti & Nordmark Expires January 3, 2012 [Page 14]