16ng Working Group S. Madanapalli Internet-Draft Samsung ISO Expires: December 16, 2006 B. Patil Nokia E. Nordmark Sun Microsystems, Inc J. Choi Samsung AIT S. Park Samsung Electronics June 14, 2006 Transmission of IPv6 over 802.16's IPv6 Convergence Sublayer draft-madanapalli-ipv6-over-802.16-ipv6cs-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 December 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IEEE 802.16d and 802.16e are air interface specifications for fixed Madanapalli, et al. Expires December 16, 2006 [Page 1] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 and mobile broadband wireless access systems. 802.16d/e is the air interface that is used in the WiMAX (Worldwide Interoperability of Microwave Access) architecture and specified by the WiMAX forum. This document defines the operation of IPv6 over the IPv6 convergence sublayer of 802.16d/e within the scope of the WiMAX network architecture. It specifies various aspects of IPv6 such as neighbor discovery, address configuration, Path MTU and the transmission/ receiving of IPv6 packets. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of 802.16d/e Convergence Sublayer . . . . . . . . . . 3 2.1. IPv6 Service-Specific Convergence Sublayer Overview . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture of WiMAX network . . . . . . . . . . . . . . . . 5 5. IPv6 Link model for IPv6 CS . . . . . . . . . . . . . . . . . 7 5.1. On-link communication . . . . . . . . . . . . . . . . . . 8 6. Transmission of IPv6 over 802.16d/e using IPv6 CS . . . . . . 8 6.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Maximum Transmission Unit . . . . . . . . . . . . . . . . 9 6.3. IPv6 Prefix Assignment . . . . . . . . . . . . . . . . . . 10 7. IPv6 Neighbor Discovery Procedures . . . . . . . . . . . . . . 10 7.1. Router Discovery . . . . . . . . . . . . . . . . . . . . . 10 7.1.1. Router Solicitation . . . . . . . . . . . . . . . . . 10 7.1.2. Router Advertisement . . . . . . . . . . . . . . . . . 10 7.1.3. Router Lifetime and Periodic Router Advertisements . . 10 7.2. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 11 7.3. Address Resolution . . . . . . . . . . . . . . . . . . . . 11 7.4. Next-Hop Determination . . . . . . . . . . . . . . . . . . 11 7.5. Neighbor Unreachability Detection (NUD) . . . . . . . . . 11 8. Address Autoconfiguration . . . . . . . . . . . . . . . . . . 12 8.1. Stateless Address Autoconfiguration . . . . . . . . . . . 12 8.2. Stateful Address Autoconfiguration . . . . . . . . . . . . 12 9. Duplicate Address Detection . . . . . . . . . . . . . . . . . 12 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 13 9.2. Relay DAD Procedure . . . . . . . . . . . . . . . . . . . 13 9.2.1. MS Behavior . . . . . . . . . . . . . . . . . . . . . 15 9.2.2. AR Behavior . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Madanapalli, et al. Expires December 16, 2006 [Page 2] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 1. Introduction IEEE 802.16d/e [1], [2] is the wireless MAN air interface standard. 802.16d/e specifications cover the PHY and MAC layers of the air interface as well as the definition of several convergence sublayers (CS) above the MAC which provide the capability for transmission of ATM, IPv4/6, Ethernet and others. The network working group (NWG) in WiMAX forum [11], which is an industry consortium, is specifying the network architecture and documenting the operation of IPv4, IPv6 and, Ethernet (802.3, 802.1q). The scope of this document is limited to the specification of IPv6 over the IPv6 convergence sublayer of 802.16d/e. This document specifies the link model in the context of the WiMAX network architecture using the IEEE 802.16d/e air interface specification as well as the operation of the various IPv6 features such as Neighbor discovery, Address autoconfiguration, Path MTU among others. 2. Overview of 802.16d/e Convergence Sublayer The 802.16d/e MAC comprises of three sublayers: - The service specific CS - The MAC common part sublayer (CPS) - The security sublayer For details of the functionality of these sublayers, please refer to the 802.16d/e specifications [1], [2]. Multiple CSs are provide for interfacing with various protocols. The internal format of the CS is unique to the CS and the MAC CPS has no necessity to understand or parse the CS payload. The service specific CS resides above the MAC CPS and is responsible for accepting and processing the higher layer PDUs (Packet Data Unit) which includes classification of the higher layer PDUs and delivering it to the appropriate MAC SAP (Service access point) and receiving PDUs from the peer entity. The primary task of the convergence sublayer is to classify service data units (SDUs) to the proper MAC connection (CID). Currently the two main CSs provided are: ATM CS and Packet CS. Packet CS supports IEEE 802.3, IEEE 802.1Q, IPv4 and, IPv6 PDUs via their own specific CS. Within the context of this document, IPv6 CS is relevant. Madanapalli, et al. Expires December 16, 2006 [Page 3] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 2.1. IPv6 Service-Specific Convergence Sublayer Overview IPv6 CS is responsible for the transmission and reception of IPv6 packets. The IPv6 layer interfaces to the IPv6 CS as shown in the figure below: +-------------------+ | ULP | +-------------------+ | | V +-------------------+ | IPv6 | +-------------------+ | | MAC-SSCS SAP V +-------------------+ | 802.16 IPv6 CS | +-------------------+ | | MAC-CPS SAP V +-------------------+ | 802.16 MAC CPS | +-------------------+ Figure 1. 802.16 MAC Sublayers In case of IPv6 CS the classification parameters constitute of IPv6 Header and Transport Header. The following parameters are used as classifiers in case of IPv6 CS: IPv6 source and destination addresses, next header in the last header of the IP header chain, Traffic Class, and, source and destination port numbers. The following are the list of functions that IPv6 CS performs: a. Classification of an IPv6 packet to an appropriate MAC Connection b. Suppression of IPv6 Header, called Payload Header Suppression (PHS) (optional) c. Delivery of the resulting IPv6 CS PDU to the MAC-CPS SAP to delivery to the peer MAC-CPS SAP. d. Receipt of the IPv6 CS PDU from the MAC-CS SAP Madanapalli, et al. Expires December 16, 2006 [Page 4] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 e. Rebuilding the IPv6 header if PHS is in use. 3. Terminology Access Router (AR): A layer 3 entity that acts as a first-hop default router for the MSs. The WiMAX network architecture defines the concept of an Access Service Network (ASN) which is a logical boundary and an aggregation of functions. The ASN Gateway (ASN-GW) is a logical entity that represents an aggregation of control plane functions in addition to performing bearer plane routing or bridging function. The IPv6 AR is a function of the ASN-GW when the base station (BS) and ASN-GW are split and is a function of the ASN in the case of an integrated entity which includes the BS and other functions. Base Station (BS): A layer 2 entity conforming to 802.16 suite of standards that transmit Layer 3 PDUs between MS and AR unchanged. Convergence Sublayer (CS): The service-specific convergence sublayers (called Convergence Layers in this document) interfaces to higher layers, above the core MAC common part sublayer. The primary task of the convergence sublayer is to classify upper layer service data units (SDUs) to the proper MAC connection. Mobile Station (MS): An end-user equipment that provides connectivity to 802.16 based networks. The terms MS, SS (Subscriber Station) and host are used interchangeably in this document. Transport Connection: An 802.16 based MAC connection between an MS and a BS with a 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). 4. Architecture of WiMAX network In WiMAX networks, ASN GW plays the role of Access Router (AR). An MS is attached to only one ASN GW at a given time. ASN-GW manages the information (including IP address) of all MSs on the link. Subsequent to network entry, an MS is provided with an initial Madanapalli, et al. Expires December 16, 2006 [Page 5] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 transport connection, Initial Service Flow, to communicate with the AR to get the IP address and other host configuration information. The following figures illustrates high level view of the elements in the WiMAX network architecture that are involved in enabling IPv6: +-----+ | MS1 |-----+ +-----+ | | | +-----+ | +-----+ +-----------+ | MS2 |-----+-----| BS1 |----------| AR/ASN-GW |-----[Internet] +-----+ | +-----+ +-----------+ . | ____________ . | ()__________() +-----+ | L2 Tunnel | MSn |-----+ +-----+ Figure 2. WiMAX N/W Architecture: 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. +-----+ | MS1 |-----+ +-----+ | | | +-----+ | +--------------+ | MS2 |-----+-------| BS/AR/ASN-GW |-----[Internet] +-----+ | +--------------+ . | . | +-----+ | | MSn |-----+ +-----+ Figure 3. WiMAX N/W Architecture: BS and AR in one box Madanapalli, et al. Expires December 16, 2006 [Page 6] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 The above figure shows the case where BS and AR co-exist as a single entity. In either case, the AR is the first hop IPv6 Router for an MS/SS. 5. IPv6 Link model for IPv6 CS The link between the MS and the AR at the IPv6 layer is viewed as a shared link. 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. However the tunneled link between the BS and AR can also be a shared link which supports multiple MSs. The lower-layer link between the MS and BS is referred to as a MAC transport connection and is identified uniquely within the scope of a BS by a Connection Identifier (CID). The figure below shows the link model for IPv6: MS +----+ +----+ | | IPv6 (Shared link) | | | L3 |=======================================| | | | | | |----| PTP conn. +----+ L2 Tunnel | AR |---[Internet] | L2 |--------------| BS |===================| | | | | | | | +----+ +----+ | | | | +----+ L2 Tunnel | | | BS |===================| | | | | | +----+ +----+ Figure 4. IPv6 link model in WiMAX Networks 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. In the case of WiMAX, subsequent to the MS performing Registration (an 802.16 procedure), there exists an initial L2 transport connection between the MS and the AR which enables the sending and receiving of IPv6 packets without any IPv6 address for the MS. Madanapalli, et al. Expires December 16, 2006 [Page 7] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 5.1. On-link communication The IPv6 link is a shared link. Hence from that perspective it appears to an MS that it can reach any other MS on the same link directly. However in reality the lower-layer is a point-to-point link and all IPv6 packets between hosts that are on the same IPv6 link have to be transmitted via the AR. Packets originated by an MS always are sent to the AR for delivery to a destination. When the destination is another MS which is on the same IPv6 link, the AR sends the packet unchanged to the destination MS, i.e. the AR does not decrement the hop limit while forwarding the packet within the link. 6. Transmission of IPv6 over 802.16d/e using IPv6 CS IPv6 packets between the host/MS and BS are transmitted by encapsulating the IPv6 packet in 802.16 frame with 6 octet MAC header. MS +-------+ | UL | |-------| | IPv6 | BS |-------| +-------+ |IPv6CS |--------//--------|IPv6CS | |-------| 802.16d/e |-------| | MAC | | MAC | |-------| |-------| | PHY | | PHY | +-------+ +-------+ Figure 5. Transmission of IPv6 over IPv6 CS 6.1. Frame Format IPv6 packets are transmitted in Generic 802.16 MAC frames as shown in the following figure. Madanapalli, et al. Expires December 16, 2006 [Page 8] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|E| Type |R|C|EKS|R|LEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN LSB | CID MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID LSB | HCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CRC (optional) | +-+-+-+-+-+-+-+-+ Figure 6. 802.16 Frame Format H: Header Type (1 bit). Shall be set to zero indicating that it is a Generic MAC PDU. E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload is encrypted. R: Reserved. Shall be set to zero. C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included EKS: Encryption Key Sequence LEN: The Length in bytes of the MAC PDU including the MAC header and the CRC if present (11 bits) CID: Connection Identifier (16 bits) HCS: Header Check Sequence (8 bits) CRC: An optional 8-bit field. CRC appended to the PDU after encryption. Type: This field indicates the subheaders (Mesh subheader, Fragmentation Subheader, Packing subheader etc and special payload types (ARQ) present in the message payload 6.2. Maximum Transmission Unit The 802.16d/e link has an MTU of 1522 octets. Hence the MTU of the IPv6 packets can be configured to be 1500 octets as the recommendation in [3]. However because of a tunnelled interface between the BS and the Access router (AR), it makes sense to limit Madanapalli, et al. Expires December 16, 2006 [Page 9] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 the MTU to a value less than 1500 octets. A value of 1400 octets is recommended for the MTU on the IPv6 hosts. Router advertisements can however override the recommended MTU and specify an appropriate value which is 1500 octets or less. 6.3. IPv6 Prefix Assignment The IPv6 link between MSs and the AR is a shared link. An IPv6 prefix is shared by all the nodes which are on the same link. The prefix is assigned to the nodes with On-link flag (L-flag) reset so that the nodes may not make on-link assumption for the addresses whose prefix matches with sending node prefix. 7. IPv6 Neighbor Discovery Procedures 7.1. Router Discovery 7.1.1. Router Solicitation An MS can send a Router Solicitation message to solicit a Router Advertisement message from the AR to acquire necessary information as specified in [4]. On completion of the network attachment procedure (802.16 specific), an initial transport connection is established between the MS and the AR. The MS should send a router solicitation as soon as this connection is established. An MS that is network attached may also send router solicitations at any time. 7.1.2. Router Advertisement Upon receiving a Router Solicitation or as soon as the initial transport connection following the network attachment procedure is established, the AR sends a router advertisement. As there is only one AR at any given time serving an MS which receives a Router Solicitation from an MS, the Router Advertisement can be sent without any random delay. AR may send unsolicited Router Advertisements periodically as specified in [4]. 7.1.3. Router Lifetime and Periodic Router Advertisements The router lifetime should be set to a large value, preferably in hours. 802.16d/e hosts have the capability to transition to an Idle mode in which case the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile which is in Idle mode and consuming resources on the air interface, the interval between Madanapalli, et al. Expires December 16, 2006 [Page 10] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 periodic router advertisements should be set quite high. The MaxRtrAdvInterval should be configurable to a value which is greater than 1800 seconds and less than 14400 seconds. 7.2. Prefix Discovery The 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 prefixes are advertised with on-link flag (L-bit) reset so that the MSs may not make any assumption about existence of on-link neighbors. In PIO, a prefix may be advertised with autonomous address-configuration flag (A-bit) set. The MSs on the link uses the prefix with A-bit set for auto- configuring an IPv6 address in a stateless manner as specified in [5]. All Router Advertisements should contain all the prefixes assigned to the IPv6 link. To enable this, the link should not be assigned with too many prefixes so that all the PIOs can be sent in a single Router Advertisement. 7.3. Address Resolution When IPv6 is supported over the IPv6 CS in the case of 802.16d/e, the IPv6 layer sits directly over the 802.16d/e MAC layer. The MAC address of the host is not used in the MAC header. Instead a Connection Identifier (CID) is used. As s result address resolution is not required in this case. However an MS or an AR may perform address resolution if they have been implemented as per IPv6 suite of specifications. In such cases the AR can relay the address resolution request to the MS that is owning the target IPv6 address so that the actual MS responds to the address resolution query. An intelligent/future implementation may choose not to do the address resolution if the access technology is 802.16d/e with IPv6 CS. 7.4. Next-Hop Determination The Next-hop for an MS is always the AR and so Next-Hop resolution may be trivial. An intelligent/future implementation of a host may choose not to do the next-hop determination if the access technology is 802.16d/e. 7.5. Neighbor Unreachability Detection (NUD) For an MS the only neighbor is the AR and hence the MS can avoid the NUD which can be derived from the MAC layer functionality e.g. existence of a MAC transport connection. However the AR must perform NUD as defined in [4] using NS/NA exchange as the MS may have Madanapalli, et al. Expires December 16, 2006 [Page 11] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 multiple addresses at any given time. 8. Address Autoconfiguration MSs can configure their addresses using either stateless address autoconfiguration or stateful configuration with DHCPv6. 8.1. Stateless Address Autoconfiguration Stateless address autoconfiguration is performed as specified in [5]. 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 [7]. The address configured through stateless address autoconfiguration must pass the duplicate address detection test before being assigned to the interface. 8.2. Stateful Address Autoconfiguration The Stateful Address Autoconfiguration is invoked if the M-flag is set in the Router Advertisement. Obtaining the IPv6 address through stateful address autoconfiguration method is specified in the [8]. The address configured through stateful address autoconfiguration must pass the duplicate address detection test before being assigned to the interface. 9. Duplicate Address Detection The IPv6 link is viewed as a shared link. However the DAD procedure as specified in [5] does not adapt well to the 802.16d/e air interface. In order to optimize the air interface and to conserve the battery life of MSs that are in Idle mode, it is not recommended to multicast the NS messages to all hosts on the link. An enhancement to the DAD mechanism is specified here for use in the case of IPv6 over 802.16d/e. The WiMAX IPv6 AR is aware of all the IPv6 addresses configured by the hosts for which it is the serving AR. When an MS initiates the DAD procedure by sending a DAD NS, the AR looks at its authoritative address cache to determine if the target address in DAD NS is a duplicate. If a match exists, the AR relays the DAD NS to the MS that currently is configured with that address. The MS which owns the address defends the address as specified in [5] by sending a DAD NA which is relayed via the AR to the MS performing the DAD procedure. Madanapalli, et al. Expires December 16, 2006 [Page 12] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 9.1. Conceptual Data Structures In order to enable Relay DAD, the AR needs to maintain the following information for each interface. Authoritative Address Cache: A set of entries about the IPv6 addresses that are currently in use by the MSs belonging to the same IPv6 link as the router interface. The authoritative address Cache includes all types of addresses (link local, unique local and global addresses). The AR learns the addresses from the DAD Neighbor Solicitation and updates the address cache. The entries in the Authoritative Address Cache are deleted only if the prefix lifetime expires or the node deregisters explicitly. The link local addresses have infinite lifetime and will be deleted only when there is an explicit deregistration of the particular MS The deregistration procedure is specific to 802.16d/e and the interaction between the deregistration procedure and the deletion of the address from the authoritative address cache is outside the scope of this document. 9.2. Relay DAD Procedure The following figure illustrates the Relay DAD procedures. Madanapalli, et al. Expires December 16, 2006 [Page 13] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 +-------+ +-------+ +-------+ | MS1 | | BS/AR | | MS2 | +-------+ +-------+ +-------+ | | | | N/W Entry & Auth | | (1) |<--------------------->| | | | | | Transport conn. Est. | | (2) |<--------------------->| | | | | | | | |LLA Construction | | (3) |------+ | | | | | | |<-----+ | | | | | | MLD Join | | (4) |---------------------->| | | | | | DAD NS | | (5) |---------------------->| | | |Addr. Cache Lookup | (6) | |------+ | | | | | | |<-----+ | | | | | | DAD NS | (7) | |---------------------->| | | | | DAD NA | | (8) |<----------------------|<----------------------| | | | | | | Figure 7. Relay DAD 1. The MS1 performs initial network entry and authentication procedures as described in 802.16d/e 2. On successful completion of step 1, an initial transport connection is established between the MS and the AR. 3. MS1 constructs a Link Local Address as specified in [5]. 4. MS1 constructs a solicited node multicast address for the corresponding Link Local Address and sends MLD Join request for the solicited node multicast address. Madanapalli, et al. Expires December 16, 2006 [Page 14] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 5. MS1 starts verifying address uniqueness by sending a DAD NS on the initial MAC transport connection. The MS1 can also send a Router Solicitation simultaneously on initial MAC transport connection for Router and Prefix discovery. 6. AR looks into the authoritative address cache to check if the address is already in use 7. AR relays the DAD NS to the address owner (MS2) in case there is match in the address cache. 8. MS2 defends the address by sending DAD NA, which is relayed to MS1 via the AR. Upon on receiving the DAD NA, it discards the tentative address and behaves as specified in [5]. 9.2.1. MS Behavior The MS behavior is as specified in [5]. And it is recommended that the MS performs DAD for all addresses that it acquires before assigning to its interface even if the same Interface Identifier being reused for the new address. 9.2.2. AR Behavior The AR must implement the address cache and must not decrement the hop limit while forwarding the DAD NS to the address owner. An address that matches with the interface identifier (least 64 bits) must be considered as duplicate as some implementations may choose not to do DAD for all addresses constructed from the same interface identifier. If the MS which owns the address is in idle mode, the MS must be paged and brought to active state in order to deliver the DAD NS. The AR also required to maintain the state (MS information) for all DAD NSs that it relays, so that the DAD NA can be relayed back the DAD probing MS. 10. IANA Considerations This draft does not require any actions from IANA. 11. Security Considerations This document specifies the operation of IPv6 over the IEEE 802.16d/e air interface and hence the security aspects are equivalent to the IPv6 specifications. The IPv6 AR in the case of 802.16d/e maintains the addresses of all the hosts that it is currently serving. As a result a couple of Madanapalli, et al. Expires December 16, 2006 [Page 15] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 issues arise: 1. A malicious node may launch a DoS attack by configuring a large number of addresses and performing DAD on those. However this is not an issue since the AR is aware at the lower layer the identity of the host performing the DAD and has the ability to terminate the connection. 2. A malicious node may configure a large number of addresses and attempt to insert these in the AR's address cache. This may result in an overflow of the address cache at the AR. It is recommended that hosts in such a network be allowed to configure a limited number of addresses. This number is a configurable parameter and is implementation specific to the AR. 12. Acknowledgements TBD 13. References [1] "IEEE 802.16d, 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. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Madanapalli, et al. Expires December 16, 2006 [Page 16] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 [9] Madanapalli, S., "IPv6 Neighbor Discovery over 802.16: Problems and Goals, draft-madanapalli-nd-over-802.16-problems-00.txt(work in progress)", November 2005. [10] Bernard, B., "Multiple Encapsulation Methods Considered Harmful, draft-iab-link-encaps-00.txt (work in progress)", May 2006. [11] "WiMAX Forum, www.wimaxforum.org". Madanapalli, et al. Expires December 16, 2006 [Page 17] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 Authors' Addresses Syam Madanapalli Samsung ISO 66/1 Bagmane Tech Park CV Raman Nagar Bangalore 560093 India Phone: +91-80-41819999 Email: smadanapalli at gmail dot com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 US Email: basavaraj.patil@nokia.com Erik Nordmark Sun Microsystems, Inc 901 San Antonio Road Palo Alto, CA 94110 US Email: erik.nordmark@sun.com JinHyeock Choi Samsung AIT Communication Lab P.O.Box 111 Suwon 440-600 Korea Phone: +82-31-280-9233 Email: jinchoe@samsung.com Madanapalli, et al. Expires December 16, 2006 [Page 18] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 Soohong D. Park Samsung Electronics Mobile Platform Laboratory 416, Maetan-3dong, Yeongtong-Gu Suwon Korea Phone: +82-31-200-4508 Email: soohong.park@samsung.com Madanapalli, et al. Expires December 16, 2006 [Page 19] Internet-Draft IPv6 over 802.16's IPv6 CS June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Madanapalli, et al. Expires December 16, 2006 [Page 20]