Network Working Group F. Xia Internet-Draft B. Sarikaya Intended status: Standards Track Huawei USA Expires: February 26, 2007 B. Patil Nokia August 25, 2006 Neighbor Discovery and Address Autoconfiguration in Per-MS Subnet Prefix Model draft-xia-16ng-per-ms-prefix-nd-00 Status of this Memo 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 BCP 79. 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. 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 Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Xia, et al. Expires February 26, 2007 [Page 1] Internet-Draft ND and Address Autoconfiguration August 2006 Abstract This draft defines neighbor discovery and stateless address autoconfiguration based on IEEE 802.16d/e per-MS subnet prefix model. In this model, an MS can have multiple IPv6 addresses, but an IPv6 prefix can only be used by one MS, that is, different MSs cannot share the same prefix. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Virtual Link . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Virtual Link States Transitions . . . . . . . . . . . . . 6 3.1.1. Active . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Teardown . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Information Model . . . . . . . . . . . . . . . . . . . . 7 4. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Fast Router Discovery (FRD) . . . . . . . . . . . . . . . 8 4.2. Solicited Router Advertisement . . . . . . . . . . . . . . 8 4.3. Periodic Router Advertisement . . . . . . . . . . . . . . 8 5. Link Local Address Autoconfiguration . . . . . . . . . . . . . 9 5.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 9 5.2. Duplicate Address Detection . . . . . . . . . . . . . . . 9 6. Global Address Autoconfiguration . . . . . . . . . . . . . . . 10 7. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Reuse of existing standards . . . . . . . . . . . . . . . 11 7.2. On-link Multicast Support . . . . . . . . . . . . . . . . 11 7.3. Consistency in IP Link Definition . . . . . . . . . . . . 11 7.4. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 11 7.5. Effect on Dormant Mode . . . . . . . . . . . . . . . . . . 11 7.6. Changes on Host Implementation . . . . . . . . . . . . . . 11 7.7. Changes on Router Implementation . . . . . . . . . . . . . 12 7.8. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12 7.9. SeND Support . . . . . . . . . . . . . . . . . . . . . . . 12 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Xia, et al. Expires February 26, 2007 [Page 2] Internet-Draft ND and Address Autoconfiguration August 2006 1. Introduction While the IEEE 802.16d/e defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16d/e MAC payload, a complete description of IPv4/IPv6 operation and deployment is not present. This draft will describe Neighbor Discovery behavior between MS and AR based on Per-MS subnet prefix model. Figure 1 illustrates the key elements of a typical IEEE 802.16d/e access network. Customer | Access Provider | Service Provider Premise | | (Backend Network) +-----+ +-----+ +------+ +--------+ | MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP +-----+ +-----+ |Router| | Router +==>Network +--+---+ +--------+ +-----+ +-----+ | | +------+ | Mss |--(802.16)--| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 1: key elements of a typical IEEE 802.16d/e access network MSs attach BS through 802.16d/e air interface. A BS manages connectivity of MSs and extend connections to an Access Router. An access router is the first IP hop router for MSs. In the shared prefix model, an IPv6 prefix is shared by multiple MSs. [IPV6CS] defines ND behavior based on this model. There are some cons in this model, such as, 1. complicated DAD because of lack of link-local multicast mechanism, 2. complicated maintenance of an authoritative address cache, especially in the scenario that address changes frequently especially when CGA based addresses are used. Shared subnet prefix model can be viewed as a kind of multilink subnets model. For a more in-depth analysis of multilink subnets, see [MULTILINK]. Per-MS subnet prefix model was first proposed for 3GPP networks in [RECOMMENDATION]. We propose a similar per-MS subnet prefix model for IEEE 802.16d/e network architecture in this document. That is, a prefix is only assigned to one MS, different MSs can't share a Xia, et al. Expires February 26, 2007 [Page 3] Internet-Draft ND and Address Autoconfiguration August 2006 prefix, and an MS can have multiple prefixes. The later sections will detail ND and address stateless autoconfiguration under this model. Xia, et al. Expires February 26, 2007 [Page 4] Internet-Draft ND and Address Autoconfiguration August 2006 2. Terminology 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 BCP 14 [STANDARDS]. subnet: generally used to refer to a topological area that uses the same address prefix, where that prefix is not further subdivided except into individual addresses. In this draft, an IPv6 prefix used stands for a subnet. link: A communication facility or physical medium that can sustain data communications between multiple network nodes, such as an Ethernet. A subnet (prefix)is associated with one link. Multiple subnets(prefixes) may be assigned to the same link. Different links can not share the same prefix. transport connection: An 802.16d/e based MAC connection between an MS and a BS with specific QoS attributes. There can be multiple connections between an MS and a BS at any given time serving different QoS requirements of the end user applications. Each connection is identified by an unique identifier called Connection Identifier (CID). In the separated model where an AR and a BS are separated physically, tunnels are established between the AR and the BS. Tunnels can be viewed as an physical extension of a transport connection. virtual link: this is a logical concept above transport connections between an MS and an AR. From IP layer perspective, there are no differences between virtual and real links. virtual interface: either end of a virtual link connects the link through a virtual interface. Each interface has a 64bit identifier which can be used for identifying the virtual link. On a given link, an MS and an AR have independent virtual interface identifiers which can be used for configuring a separate link local address, or a global IP address. Each node can have more than one virtual interface for multihoming. Xia, et al. Expires February 26, 2007 [Page 5] Internet-Draft ND and Address Autoconfiguration August 2006 3. Virtual Link An MS performs initial network entry and authentication procedures as described in 802.16d/e. Then an initial transport connection is established between an MS and an AR. The MS or AR may create, modify or delete transport connections dynamically. IPv6 operations run on transport connections. When an MS is in idle mode, all related transport connections are destroyed. The MS keeps the IPv6 address unchanged. When an MS switches off or hands off, all the connections are destroyed. The prefixes assigned should be released. A virtual link is a logical concept which consists of one or more transport connections. An MS can have one or more virtual links to an AR. Each virtual link has one or more prefixes, while each prefix can only be used in one virtual link. 3.1. Virtual Link States Transitions 3.1.1. Active When an initial transport connection is created, a virtual link is also created at the same time and the state is active. In this state, transport connections can be added, modified, and deleted to this link. From IP layer perspective, the virtual link is not any different from such links as Ethernet, PPP. ND can run on a virtual link in active state without any modifications. 3.1.2. Shutdown When an MS becomes dormant, all connections are destroyed, and related virtual link's state becomes shutdown. In this state, the MS holds it's IPv6 address, and the link attributes such as prefixes keep unchanged, but there are no ND signaling exchanges between the MS and the AR. When the MS initiates a session or receives an incoming session, one or more transport connections are added to the virtual link, and the state transits to an active one. 3.1.3. Teardown When an MS switches off or is handed over, a virtual link is torn down, and all the transport connections are destroyed. Prefixes assigned to the virtual link SHOULD be released. Xia, et al. Expires February 26, 2007 [Page 6] Internet-Draft ND and Address Autoconfiguration August 2006 3.2. Information Model Neighbor discovery protocol runs on a virtual link. When an MS receives NS/NA/RA or an AR receives NS/NA/RS from a CID, these nodes will map the CID to a related virtual link for further process. When an MS sends NS/NA/RS or an AR sends NS/NA/RA to a virtual link, these nodes will map the virtual link to a related CID for transport. Each MS and AR have a virtual link information table which include following elements: 1. virtual interface identifier which can be used to identify the virtual link. For the same virtual link, an AR and an MS create their virtual interfaces independently. In the same node, different interfaces MUST have different identifiers. 2. prefixes which are assigned to the link for address autoconfiguration. 3. CIDs which compose the virtual link. 4. optional items such as MTU and so on. When an MS hands over to another BS under the same AR, the MS and the AR deletes the existing CIDs and adds one or more new CIDs. Other attributes of this entry including prefixes are kept unchanged. When an MS becomes dormant, the MS and AR deletes all existing CIDs. When the MS becomes active again, new CIDs are created and added to the entry. Xia, et al. Expires February 26, 2007 [Page 7] Internet-Draft ND and Address Autoconfiguration August 2006 4. Prefix Assignment When an MS attaches to an AR, prefixes SHOULD be assigned to the MS. When the MS detaches from the AR, prefixes SHOULD be reclaimed. The AR can manage prefixes through DHCPv6. That is, when the AR needs to assign prefixes to an MS, it requests these prefixes from a DHCP server, and when the MS detaches the AR, the AR gives back the prefixes to the DHCP server. There are also some alternatives to manage prefixes. In this memo, how an AR assigns prefixes to an MS is our topic. 4.1. Fast Router Discovery (FRD) As soon as a virtual link becomes active, an AR sends a suitable unsolicited RA. In this message, one or more prefixes are included. 4.2. Solicited Router Advertisement When a virtual link is active, an MS sends an RS with all-routers multicast address as destination address and unspecified address as source address on the link. The AR responds with a suitable RA with all-nodes multicast address as the destination IP address and the AR link local address as the source address. 4.3. Periodic Router Advertisement When a virtual link is active, periodic router advertisement SHOULD be performed as per [DISCOVERY]. When an MS is in idle mode, the corresponding virtual link is in shutdown state, and an AR never advertises an RA message on a shutdown link. Thus an MS never wakes up just because of receiving a RA. The MaxRtrAdvInterval should be configurable to quite a high value to relieve RA traffic through air interface. Xia, et al. Expires February 26, 2007 [Page 8] Internet-Draft ND and Address Autoconfiguration August 2006 5. Link Local Address Autoconfiguration 5.1. Interface Identifier An MS can generate it's interface identifier from its MAC address as per [ARCHI]. The MS may also generate random interface identifiers as per [PESAA]. An AR generates an identifier for a virtual interface as it does for a physical one. 5.2. Duplicate Address Detection When a virtual link is created, an MS and an AR create their respective link local addresses and do DAD within the link independently. Xia, et al. Expires February 26, 2007 [Page 9] Internet-Draft ND and Address Autoconfiguration August 2006 6. Global Address Autoconfiguration An AR advertises the prefixes by putting PIO (Prefix Information Option) in the Router Advertisements and an MS learns the prefix information by consulting these PIOs. The MS and the AR concatenate prefix and interface ID to create their own global addresses independently. DAD is done within the virtual link scope. Xia, et al. Expires February 26, 2007 [Page 10] Internet-Draft ND and Address Autoconfiguration August 2006 7. Considerations 7.1. Reuse of existing standards In this model, almost all the work is focused on how to maintain a virtual link. From IP layer perspective, there is no difference between a real link and a virtual one. So, ND protocol can run on a virtual link without any modification and limitation. 7.2. On-link Multicast Support Only an MS and an AR connect to a virtual link. On-link multicast is supported, but the scope is limited. On-link multicast is the same as unicast. 7.3. Consistency in IP Link Definition In [MULTILINK], there is IP Link definition and explanation. The main idea is that a subnet is considered to be a subset of a link. That is, a link can have one or more subnets, but one subnet can only span one link. In per-MS subnet prefix model, a prefix can be viewed as a subnet. A virtual link can be assigned to one or more prefixes, while one prefix can only be used by one link. This model is consistent with original IP model. 7.4. Packet Forwarding From a data plane perspective, an AR behavior is almost the same as a router. The difference is that a router has limited static physical interfaces while an AR has many dynamic virtual interfaces. The AR broadcasts prefix route information to the Internet. An aggregated route can be used to avoid route flips. 7.5. Effect on Dormant Mode Link-local multicast is limited in a virtual link. An MS is waken up only when there is some traffic. Thus, battery can be used efficiently. 7.6. Changes on Host Implementation Virtual links MUST be maintained to provide a consistent interface to the IP layer. Any function modules above the link layer can be used without any modification. As there is very low address duplication possibility, Optimistic DAD as per [OPTDAD] is preferable. Xia, et al. Expires February 26, 2007 [Page 11] Internet-Draft ND and Address Autoconfiguration August 2006 7.7. Changes on Router Implementation Following functions should be added in an AR 1. virtual link management: to create and destroy links, and to maintain links' states. 2. prefix management: to allocate and reclaim prefixes for MSs 3. route management: to broadcast MSs route information dynamically. Prefix management can be considered with route management at the same time. For example, each AR can be assigned a /48 prefix, while an MS' /64 prefix is derived from the /48 prefix extension. 7.8. Renumbering Each prefix has it's lifetime, and multiple prefixes can be assigned to a virtual link at the same time. Renumbering function can be obtained. For example, if a carrier wants to change it's /48 prefix, all corresponding /64 prefixes MUST be advertised to MSs. Compared to the shared subnet prefix model, per-MS subnet prefix has more signaling traffic while renumbering. 7.9. SeND Support An MS can generate an virtual interface identifier of an IPv6 address by computing a cryptographic hash of the public key. SeND is supported. Xia, et al. Expires February 26, 2007 [Page 12] Internet-Draft ND and Address Autoconfiguration August 2006 8. Applicability This model is applicable for both IPv6 CS and Ethernet CS. It can be used not only Integrated AR-BS model (Profile B in WiMAX architecture) but also separated AR-BS one (Profiles A and C). Xia, et al. Expires February 26, 2007 [Page 13] Internet-Draft ND and Address Autoconfiguration August 2006 9. Security Considerations There are existing security concerns with Neighbor Discovery and Stateless Address Auto configuration. Secure Neighbor Discovery (SEND) [SEND] provides protection against the threats to Neighbor Discovery described in [NDTM]. This memo does not introduce any additional threats to Neighbor Discovery, and SEND can be used. Xia, et al. Expires February 26, 2007 [Page 14] Internet-Draft ND and Address Autoconfiguration August 2006 10. References 10.1. Normative References [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998, . [ARCHI] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4921, February 2006, . [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998, . [MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999, . [NDTM] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, . [OPTDAD] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, . [PESAA] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001, . [RECOMMENDATION] Wasserman, Ed., M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002, . [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005, . [STANDARDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . Xia, et al. Expires February 26, 2007 [Page 15] Internet-Draft ND and Address Autoconfiguration August 2006 10.2. Informative References [IPV6CS] Madanapalli, S., Patil, B., Nordmark, E., Choi, J., and S. Park, "Transmission of IPv6 over 802.16's IPv6 Convergence Sublayer", June 2006, . [MULTIENCAP] Aboba,Ed., B., Davies, Elwyn., and Dave. Thaler, "Multiple Encapsulation Methods Considered Harmful", July 2006, . [MULTILINK] Thaler, Dave., "Issues With Protocols Proposing Multilink Subnets", February 2006, . Xia, et al. Expires February 26, 2007 [Page 16] Internet-Draft ND and Address Autoconfiguration August 2006 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Email: sarikaya@ieee.org Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 Phone: Email: basavaraj.patil@nokia.com Xia, et al. Expires February 26, 2007 [Page 17] Internet-Draft ND and Address Autoconfiguration August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xia, et al. Expires February 26, 2007 [Page 18]