16ng Working Group S. Madanapalli, Ed. Internet-Draft LogicaCMG Intended status: Informational September 6, 2006 Expires: March 10, 2007 Analysis of IPv6 Subnet Models for 802.16 based Networks draft-madanapalli-16ng-subnet-model-analysis-00.txt 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 March 10, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides different IPv6 subnet models that are suitable for 802.16 based networks and provides analysis of various considerations for each subnet model and the applicability of each subnet model under different deployment scenarios. This document is a result of Design Team that has formed to analyze then IPv6 subnet models for 802.16 based networks. Madanapalli Expires March 10, 2007 [Page 1] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IPv6 Subnet Models for 802.16 based Networks . . . . . . . . . 3 3.1. Shared Prefix Model . . . . . . . . . . . . . . . . . . . 4 3.1.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 5 3.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 6 3.1.3. Duplicate Address Detection . . . . . . . . . . . . . 6 3.1.4. Considerations . . . . . . . . . . . . . . . . . . . . 6 3.1.5. Applicability . . . . . . . . . . . . . . . . . . . . 7 3.2. Unique Prefix per MN . . . . . . . . . . . . . . . . . . . 7 3.2.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 8 3.2.2. Link Local Address Autoconfiguration . . . . . . . . . 8 3.2.3. Global Address Autoconfiguration . . . . . . . . . . . 8 3.2.4. Considerations . . . . . . . . . . . . . . . . . . . . 9 3.2.5. Applicability . . . . . . . . . . . . . . . . . . . . 11 3.3. Ethernet Like Model . . . . . . . . . . . . . . . . . . . 11 3.3.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 12 3.3.2. Address Autoconfiguration . . . . . . . . . . . . . . 12 3.3.3. Duplicate Address Detection . . . . . . . . . . . . . 13 3.3.4. Considerations . . . . . . . . . . . . . . . . . . . . 13 3.3.5. Applicability . . . . . . . . . . . . . . . . . . . . 14 4. Conclusions and Relevant Subnet Model . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Madanapalli Expires March 10, 2007 [Page 2] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 1. Introduction 802.16 [1] [2]is a connection oriented access technology for the last mile without optimal bi-directional native multicast support. Traditionally IP protocols (e.g. ARP, IPv6 ND) assume the availability of multicast at the link layer. This is further complicated by the definition of commercial network models like WiMAX, which defines the Service Flows that extends the 802.16b MAC transport connection all the way to an Access Router by using a tunnel between BS and AR. This leads to multiple ways of deploying IP over 802.16 based networks. This document looks at various considerations in selecting a subnet model for 802.16 based networks and provides analysis of the various possible subnet models. 2. Terminology An end-user equipment that provides connectivity to 802.16 based networks. The terms Subscriber Station (SS), Mobile Node (MN) and host are used synonymously with MS in this document. Base Station (BS): A generalized equipment sets providing connectivity, management, and control of the subscriber station (SS). Access Router: An entity, which performs IP routing function to provide IP connectivity for MSs. In WiMAX Networks, the AR is an ASN Gateway. IP Link: This has been defined in RFC 2461 as below. - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. Point-to-multipoint: A link consists of a single interface communicating directly with more than one interface. 3. IPv6 Subnet Models for 802.16 based Networks This section provides various IPv6 subnet models for 802.16 based networks and provides their operational considerations in practical deployment scenarios. Madanapalli Expires March 10, 2007 [Page 3] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.1. Shared Prefix Model The following figures illustrates high level view of the subnet model using shared prefix for IPv6 link wherein one more prefixes advertised on the link would be used by the all nodes attached to the IPv6 link. +-----+ | MS1 |-----+ +-----+ | | | +-----+ | +-----+ +--------+ | MS2 |-----+-----| BS1 |----------| AR |-------[Internet] +-----+ | +-----+ +--------+ . | ____________ . | ()__________() +-----+ | L2 Tunnel | MSn |-----+ +-----+ Figure 1. Shared Prefix Subnet Model: Separate BS and AR The above figure shows the case where BS and AR exist as separate entities, in this case a tunnelled interface between the two exists in case of IPv6 CS. In case of Ethernet CS, the BS implements bridging(?). +-----+ | MS1 |-----+ +-----+ | | | +-----+ | +-----------+ | MS2 |-----+-------| BS/AR |-------[Internet] +-----+ | +-----------+ . | . | +-----+ | | MSn |-----+ +-----+ Madanapalli Expires March 10, 2007 [Page 4] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 Figure 2. Shared Prefix Subnet Model: BS and AR in one box The above figure shows the case where BS and AR co-exist as a single entity. In the shared prefix model, the link between the MS and the AR at the IPv6 layer is viewed as a shared link and the lower layer link between the MS and BS is a point-to-point link. This point-to-point link between the MS and BS is extended all the way to the AR when the granularity of the tunnel between the BS and AR is on a per MS basis. This is illustrated in the following figure below. MS +----+ +----+ | | IPv6 (Shared link) | | | L3 |=======================================| | | | | | |----| PTP conn. +----+ L2 Tunnel | AR |---[Internet] | L2 |--------------| BS |===================| | | | | | | | +----+ +----+ | | | | +----+ L2 Tunnel | | | BS |===================| | | | | | +----+ +----+ Figure 3. IPv6 Shared Prefix Link Model In the shared prefix mode, an AR can serve one or more BSs. All MSs connected to BSs that are served by an AR are on the same IPv6 link. 3.1.1. Prefix Assignment One or more IPv6 prefixes are assigned to the link and hence shared by all the nodes that are attached to the link. The prefixes are advertised with autonomous flag (A-Flag) set and the On-link flag (L-flag) reset for address autoconfiguration so that the nodes may not make on-link assumption for the addresses whose prefix matches with sending node prefix. Madanapalli Expires March 10, 2007 [Page 5] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.1.2. Address Autoconfiguration Both link local and global addresses are autoconfigured as specified in [4]. The Interface Identifier is generated from its MAC address as per [6]. The MS may also generate random Interface Identifiers as per the privacy extensions specification for address autoconfiguration as per [5]. The address configured through stateless address autoconfiguration must pass the duplicate address detection test before being assigned to the interface as the IPv6 link is being share with the nodes. 3.1.3. Duplicate Address Detection The DAD procedure as specified in [4] does not adapt well to the 802.16 air interface. An optimization, called Relay DAD, may be required to perform DAD. For more details refer [?]. 3.1.4. Considerations 3.1.4.1. Reuse of existing standards The shared prefix model uses the existing specification and does not required any protocol changes or any new protocols. However this model requires implementation changes for DAD optimization. 3.1.4.2. On-link Multicast Support No native on-link multicast is possible with this method. However the AR can implement proxy mechanism for the in-link multicast if required. 3.1.4.3. Consistency in IP Link Definition The definition of IPv6 link is consistent for all procedures and functionalities except for the support of native on-link multicast support. However this can be supported with AR proxying for the multicast packets, which may increase the complexity of the AR implementation. 3.1.4.4. Packet Forwarding All MSs send the packets to the AR irrespective of the destination and scope of the IPv6 address. AR handles the packets with IPv6 global addresses normally. However the packets with link local destination addresses are relayed by the AR to destination without decrementing the hop-limit. Madanapalli Expires March 10, 2007 [Page 6] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.1.4.5. Effect on Dormant Mode This subnet model does not use any multicast and has no adverse effect on MSs that are in dormant mode. 3.1.4.6. Changes on Host Implementation This subnet model does not require any implementation changes on the host side. However the hosts required to perm duplicate address detection for all addresses even if the host is reusing the interface identifier. 3.1.4.7. Changes on Router Implementation This subnet model requires major implementation changes on the AR for supporting Relay DAD. Relay DAD requires the maintenance of Address Cache containing the list of all addresses that are in use on a particular link. This can be affected by the packet loss, host not performing DAD when reusing the IID. There can also be possible DoS attack from the hosts by configuring more number of addresses to overflow the address cache which requires the operator to limit the number of IPv6 address a host can have at any given instance. 3.1.4.8. Renumbering It is easy to renumber the IPv6 link with this model and requires just one more prefix. The number of prefixes required to renumber is O(1) compared to point-to-point link model which requires O(n) where n is the number of hosts attached to the AR, 1 < n < 2^64. 3.1.4.9. SeND Support This subnet model is SeND friendly. 3.1.5. Applicability This subnet model works with IPv6 CS and is chosen by the WiMAX Networks by the WiMAX Forum Network Working Group. 3.2. Unique Prefix per MN In WiMAX, the link between mobile node and AR is established when mobile node enters the network. This process is called initial service flow (ISF) establishment. ISF is composed of two segments, an air-link between the mobile node and BS and a tunnel between BS and AR. After ISF is established, AR which acts as the first hop router and mobile node take part in stateless address configuration and mobile node is allocated one or more unique prefixes. These Madanapalli Expires March 10, 2007 [Page 7] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 prefixes are not shared by any other nodes. The unique prefix per mobile node address model follows the recommendations of [7]. The point-to-point connection between the AR and mobile node can be implemented at the physical/MAC level. One way to accomplish this is to run PPP on the link [7]. However PPP cannot be used because IEEE 802.16 did not define PPP Convergence Sublayer. Instead, from IP layer perspective, ISF can be viewed as a virtual point to point link, called virtual link. It is straightforward to implement the virtual links on IPv6, Ethernet and VLAN [9] Convergence Sublayers. 3.2.1. Prefix Assignment If PPP is run on the link, no prefix assignment is necessary. The ASN Gateway uses IPV6CP to assign an address to the mobile node's PPP interface. If PPP is not run on the link, prefixes are assigned to the link using standard RFC 2461 Router Advertisement and Router Solicitation/ Router Advertisement mechanisms. The AR assigns a unique prefix or set of prefixes for each mobile node to AR link by including Prefix Advertisement Options for only those prefixes, when Router Advertisements are sent to the mobile node on the link. The 'L' flag in the Prefix Advertisement Option is set to 1, because the prefixes are on link. 3.2.2. Link Local Address Autoconfiguration Mobile nodes perform link local address autoconfiguration exactly as specified in RFC 2462, including duplicate address detection. Because there is only one other node on the link, the AR, there is only a possibility of an address conflict with the AR. This conflict can be easily avoided if the AR's link local address is taken into consideration when forming a link local address on the mobile node. 3.2.3. Global Address Autoconfiguration Mobile nodes perform global address autoconfiguration exactly as in RFC 2462, including duplicate address detection. The interface identifier can be either an EUI-64 identifier or a SEND CGI identifier, or possibly some other as yet undefined interface identifier generation scheme. Again, there is only a possibility of an address collision with the AR, so collisions are statistically very unlikely, and easy to fix if they should occur. If DHCP is used for address configuration ('M=1' in the Router Advertisement), the DHCP server must provide addresses with a separate prefix per mobile node. The prefix must of course match Madanapalli Expires March 10, 2007 [Page 8] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 whatever prefix the ASN Gateway has advertised to the mobile node (if any). 3.2.4. Considerations 3.2.4.1. Reuse of existing standards This solution reuses RFC 2461, 2462, and if PPP is used, RFC 2472. No changes in these protocols are required, the protocols must only be configured properly. If PPP is not used, any VLAN solution, such as IEEE 802.1Q [9], can be used 3.2.4.2. On-link Multicast Support Since the link between a mobile node and the AR is point to point, any multicast can only be sent by one or the other node. Link local multicast between other nodes and the AR will not be seen will not be seen. 3.2.4.3. Consistency in IP Link Definition The IP link is fully consistent with a standard IP link, without exception. The definition is as a point-to-point link. 3.2.4.4. Packet Forwarding The mobile node always sends all packets to the AR, because it is the only other node on the link. Link local unicast and multicast packets are also forwarded only between the two. When the unique prefix per mobile node model is used, the BS acts as a bridge. For each mobile node, the BS bridges the unique prefix or set of prefixes assigned by the AR to the link between itself and the mobile node. This means, in particular, that the per mobile node prefix or set of prefixes are routed on both sides (wireless and wired) of the BS, and that the BS needs to participate in all 802 standard bridging protocols. 3.2.4.5. Effect on Dormant Mode The AR can simply send link local multicast, for example unsolicited Router Advertisements, and the BS can filter them out. The BS knows whether a particular mobile node is in dormant mode based on 802.16e signaling. This does not require any additional IP level or MAC level protocol between the BS and AR. Madanapalli Expires March 10, 2007 [Page 9] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 If the mobile node is in dormant mode and the AR receives a packet for one of the mobile node's global addresses (unicast or subscribed multicast), it can send a Neighbor Solicitation to awaken the mobile node, according to standard RFC 2461 procedures (note that the AR could even time out the mobile node's Neighbor Cache entry as is usual for IPv6, but there are other reasons why this might not be desirable). Upon receipt of the Neighbor Solicitation at the BS, the BS can initiate paging procedures using the 802.16e paging signaling. When the traffic channel is up, the BS can forward the Neighbor Solicitation to the mobile node over the traffic channel, and the mobile node can reply with a Neighbor Advertisement that the BS then forwards to the AR. In this way, dormant mode paging falls out as a natural consequence of standard IPv6 local link Neighbor Discovery mechanisms, rather than requiring additional protocol support. 3.2.4.6. Changes on Host Implementation Host implementations follow standard IPv6 stack procedures. No changes needed. 3.2.4.7. Changes on Router Implementation If PPP is used, no changes in router implementations are needed. If PPP is not used, the AR must be capable of doing the following: 1. Each mobile node is assigned a separate VLAN when 802.1X [10] or other link level authentication procedures are complete, 2. The AR must be configured to include a unique prefix or set of prefixes for each mobile node. This unique prefix or set of prefixes must be included in Router Advertisements every time they are sent, and, if DHCP is used, the addresses leased to the mobile node must include only the unique advertised prefixes. Note that, depending on the router implementation, these functions may or may not be possible with simple configuration. No protocol changes are required, however. 3.2.4.8. Renumbering Compared to the shared subnet prefix model, per-MS subnet prefix has more signaling traffic while renumbering. 3.2.4.9. SeND Support SEND is fully supported by this model. Even though the link is point to point, mobile nodes and ARs are still encouraged to use SEND. Madanapalli Expires March 10, 2007 [Page 10] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.2.5. Applicability In enterprise networks, shared services including printers, fax machines, and other such on-line services are often available in on the local link. These services are typically discovered using some kind of link local service discovery protocol. The unique prefix per mobile node model is not appropriate for these kinds of deployments, since it is not possible to have shared link services in the ASN. The unique prefix per mobile node model is applicable to deployments where there are no shared services in the ASN. Such deployments are typical of service provider networks where a public access wireless network is being provided. Cellular networks such as UMTS are an example. 3.3. Ethernet Like Model The following figures illustrates an example of Ethernet like shared prefix model. Important point here is that Ethernet like subnet prefix model essentially functions like real Ethernet model, which means the model works as described in [3], [4]. There are some interesting questions about how to support IPv6 over Ethernet like shared model since full Ethernet functionality may be implemented on top of IEEE 802.16 point-to-multipoint links. In the Ethernet like shared model, an IPv6 prefix is shared by multiple MSs on top of IEEE 802.16 point-to-multipoint links. So, there are some considerations about DAD optimization. It also needs to describe a scheme for configuration and provisioning of an IEEE 802.16 network so that it emulates a broadcast network in a manner similar to Ethernet. In addition, multiple access routers can exist. +-----+ +-----+ +-----+ ISP 1 | MS1 |------+ +--| AR1 |----| ER1 |=== Network +-----+ | | +-----+ +-----+ +-----+ | +-----+ | | MS2 |------+-----| BS1 |--| +-----+ +-----+ | +-----+ +-----+ ISP 2 +--| AR2 |----| ER2 |=== Network +-----+ +-----+ +-----+ | +-----+ +-----+ |Hosts|----|MS/GW|------------| BS2 |--+ +-----+ +-----+ +-----+ A network behind MS may exist Figure 4: Shared Model like Ethernet Madanapalli Expires March 10, 2007 [Page 11] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 One way to construct an Ethernet like shared link is to implement bridging between all BSs with IEEE 802.16 providing the links between the MSs and the bridge on top of the BS like switched Ethernet. ------------ IPv6 Shared Link -------------------- | | | | ETH ETH ETH ETH | | | | | | | +----+----+ | | | | Bridge | | | | +-+-+-+-+-+ | | | | | | | +--+--+ -+--+ +--+--+ +-+-+-+-+-+ | MAC | | MAC | | MAC | | MAC | +-----+ +-----+ +-----+ +---------+ | PHY | | PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | +-------|-+-------|-+----CID#w----+ | | | | | +------CID#x------+ | | | +----------------CID#y--------+ | +--------------------------CID#z----------+ MS#1 MS#2 MS#3 BS Figure 5: A Bridging Example of IPv6 over Ethernet Link Model 3.3.1. Prefix Assignment In this model, multiple BSs and MSs form an IPv6 subnet and multiple prefixes are allocated to the IPv6 subnet. All MSs attached to different BSs under the same AR, can be on same IPv6 subnet. Multiple access routers can exist. Prefixes are assigned as specified in [3], [4]. 3.3.2. Address Autoconfiguration Like other IEEE 802 interfaces, the Interface Identifier for an IEEE 802.16 interface is based on the EUI-64 identifier derived from the interface's built-in 48-bit IEEE 802 address. The IPv6 link-local address for an IEEE 802.16 interface is formed by appending the Interface Identifier to the link-local prefix. A MS can generate an Identifier of an IPv6 address by computing a cryptographic hash of the public key. CGAs can be also supported. The address must do the duplicate address detection before being assigned to the interface. Madanapalli Expires March 10, 2007 [Page 12] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.3.3. Duplicate Address Detection The DAD procedure as specified in [3] does not adapt well. Any optimizations that may be possible to reduce DAD packets are required. A DAD optimization may be required for the Ethernet like shared prefix model. 3.3.4. Considerations 3.3.4.1. Reuse of existing standards All the IPv6 standards can be preserved or reused, but the scope is limited or some implementation changes for DAD or on-link multicast optimization is required. 3.3.4.2. On-link Multicast Support Downlink connections can be shared among multiple MSs, enabling multicast channels with multiple MSs receiving the same information from the BS. Multicast is not enabled in the uplink but must be realized by an entity on top the IEEE802.16 MAC sending packets received on a unicast uplink downstream on a multicast channel. So, on-link multicast can be emulated by efficiently bridging between all BSs with IEEE 802.16 providing the links between the MSs and the bridge on top of the BS, and/or downlink multicast. Any optimizations that may be possible to reduce the on-link multicast are required. 3.3.4.3. Consistency in IP Link Definition This model has consistency in IP link definition. 3.3.4.4. Packet Forwarding When properly configured and assisted by a simple bridging function, IEEE 802.16 can emulate a simple broadcast network like Ethernet. 3.3.4.5. Effect on Dormant Mode Ethernet-like broadcast transmission does not only consume more radio resources than usually needed for unicast transmission but also causes the MSs to receive and process the packets regardless of the necessity. Especially in mobile networks with many stations staying for long periods in idle modes and power down modes this causes a considerable consumption of scarce battery power. Madanapalli Expires March 10, 2007 [Page 13] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 3.3.4.6. Changes on Host Implementation No special impact on host implementation except bridging or multilink subnet functions for Ethernet like broadcast (multicast) network emulation. 3.3.4.7. Changes on Router Implementation No special impact on router implementation under a separated AR-BS model, if bridging is implemented in BS. Some networks e.g. WiMAX Networks may require bridging to be implemented in AR (ASN Gateway). 3.3.4.8. Renumbering It is easy to renumber the IPv6 link with this model and requires just one more prefix and one router advertisement. 3.3.4.9. SeND Support SEND is fully supported by this model. 3.3.5. Applicability This model is applicable for both IPv6 CS and Ethernet CS, but in terms of supporting plain end-to-end Ethernet connectivity, Ethernet CS may be more appropriate than IPv6 CS. 4. Conclusions and Relevant Subnet Model TBD 5. Security Considerations This document provides the analysis of various IPv6 subnet models for 802.16 based networks and does not introduce any new security threats. Nonetheless, this document encourages usage of SeND for securing the neighbor discovery messages on any IPv6 link. 6. IANA Considerations This document has no actions for IANA. Madanapalli Expires March 10, 2007 [Page 14] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 7. Acknowledgements This document is a result of discussions in v6subnet design team for IPv6 Prefix Model Analysis. The members of this design team in alphabetical order are: Dave Thaler, David Johnston, Junghoon Jee, Max Riegel, Myungki Shin and Syam Madanapalli. The discussion in the DT has been benefited from the active participation of James Kemp, Behcet Sarikaya, Basavaraj Patil and JinHyeock Choi in the DT mailing list. The DT thanks the chairs (Gabriel Montenegro Soohong Daniel Park) and Shepherding AD (Jari Arkko) for their active participation and motivation. 8. Contributors The members who provided the text based on the DT discussion are: Myung-Ki Shin ETRI myungki.shin@gmail.com James Kempf DoCoMo Communications Labs USA kempf@docomolabs-usa.com Soohong Daniel Park Samsung Electronics soohong.park@samsung.com JinHyeock Choi Samsung Advanced Institute of Technology jinchoe@samsung.com Behcet Sarikaya Huawei USA sarikaya@ieee.org 9. References [1] "IEEE 802.16-2004, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed broadband wireless access systems", October 2004. [2] "IEEE 802.16e, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems", October 2005. Madanapalli Expires March 10, 2007 [Page 15] Internet-Draft IPv6 Subnet Models for 802.16 September 2006 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [7] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [9] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q", May 2003. [10] "IEEE, Port-based Network Access Control, IEEE 802.1X", December 2004. Author's Address Syam Madanapalli (editor) LogicaCMG 125 Yemlur P.O. Off Airport Road Bangalore 560037 India Email: smadanapalli@gmail.com Madanapalli Expires March 10, 2007 [Page 16] Internet-Draft IPv6 Subnet Models for 802.16 September 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). Madanapalli Expires March 10, 2007 [Page 17]