Network Working Group S. Madanapalli Internet-Draft Samsung ISO Expires: June 2, 2006 November 29, 2005 IPv6 Neighbor Discovery over 802.16: Problems and Goals draft-madanapalli-nd-over-802.16-problems-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 June 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft provides overview of 802.16 Network characteristics and Convergence Sublayers, and specifies the problems in running the IPv6 Neighbor Discovery over 802.16 Networks. This document also presents the goals that point at relevant work to be done either at IETF or some other standards body. Madanapalli Expires June 2, 2006 [Page 1] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 802.16 Convergence Sublayers Overview . . . . . . . . . . . . 3 2.1. Ethernet Convergence Sublayer . . . . . . . . . . . . . . 4 2.2. IPv6 Convergence Sublayer . . . . . . . . . . . . . . . . 5 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Root Causes . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Multicast Support . . . . . . . . . . . . . . . . . . 6 3.1.2. Subnet Model . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Transport Connection for IP Signaling . . . . . . . . 8 3.2. Problems with Neighbor Discovery over 802.16 . . . . . . . 8 3.2.1. Router Discovery . . . . . . . . . . . . . . . . . . . 8 3.2.2. Prefix Assignment . . . . . . . . . . . . . . . . . . 9 3.2.3. Address Autoconfiguration . . . . . . . . . . . . . . 9 3.2.4. Address Resolution . . . . . . . . . . . . . . . . . . 9 3.2.5. Neighbor Cache . . . . . . . . . . . . . . . . . . . . 10 3.2.6. Next-Hop . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.7. Neighbor Unreachability Detection (NUD) . . . . . . . 10 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Madanapalli Expires June 2, 2006 [Page 2] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 1. Introduction 802.16 is a point-to-multipoint connection oriented technology for the last mile without bi-directional native multicast support. IPv6 Neighbor discovery supports various functions for on-link determination and communication for which it depends on subnet model and multicast support. It is unclear for 802.16 networks what constitutes a subnet. It is further complicated by Convergence Sublayers (Ethernet CS and IPv6 CS). Also during the network entry, when Mobile Station (MS) (802.16 host or Subscriber Station (SS)) joins a Base Station (BS), the MS needs a transport connection for Layer 3 signaling for Address Autoconfiguration. This document provides quick overview of Convergence Sublayers (Ethernet CS and IP CS) and how they impact the subnet model. It then provides the problems in running IPv6 Neighbor Discovery over 802.16 networks and goals for designing a solution for the problems stated in this document. The Problems and goals mentioned here may point at relevant work that can be done within the IETF as well as work to be done in other standards bodies (e.g. WiMAX NWG). 2. 802.16 Convergence Sublayers Overview The 802.16 MAC includes service-specific convergence sublayers (called Convergence Layers in this document) that interface to higher layers, above the core MAC common part sublayer that carries out the key MAC functions. The 802.16 Standard defines two general Convergence Sublayers for mapping services to and from 802.16 MAC connections. The ATM Convergence Sublayer is defined for ATM services, and the Packet Convergence Sublayer is defined for mapping packet services such as IPv4, IPv6, Ethernet, and virtual local area network (VLAN). The primary task of the convergence sublayer is to classify service data units (SDUs) to the proper MAC connection (CID). The following are the list of functions that a Convergence Sublayer performs: 1. Classification of higher layer PDU to an appropriate MAC Connection 2. Suppression of higher layer PDU header, called Payload Header Suppression (PHS) (optional) Madanapalli Expires June 2, 2006 [Page 3] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 3. Delivery of the resulting CS PDU to the MAC-CPS SAP to delivery to the peer MAC-CPS SAP. 4. Receipt of the CS PDU from the MAC-CS SAP 5. Rebuilding the higher layer PDU header if PHS is in use. In this document only Ethernet and IPv6 convergence Sublayers are considered for providing initial solution. When the Working Group feels appropriate to consider other sublayers, this document will be updated with those convergence sublayers. +-------------------+-------------------+ | Ethernet | IPv6 | +-------------------+-------------------+ | | | MAC-SSCS SAP | | | V V +-------------------+-------------------+ | Ethernet CS | IPv6 CS | +-------------------+-------------------+ | | | MAC-CPS SAP | | | V V +---------------------------------------+ | MAC-CPS | +---------------------------------------+ Figure 1 2.1. Ethernet Convergence Sublayer The following parameters are used as classifiers in case of Ethernet CS: destination MAC address, source MAC address and Ethertype. For IP over Ethernet, IP headers may be included in classification. However Ethernet CS does not specify the Ethernet Emulation on 802.16 networks. In case of Ethernet CS, the Ethernet frame from MS is delivered to AR and hence the IP link constitutes from MS to AR. And all MSs attached to same BS can be on same IP link. Madanapalli Expires June 2, 2006 [Page 4] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 +----+ +----+ +----+ | MS |----------| BS |----------| AR | +----+ +----+ +----+ Figure 2 Section 12.3.1.1. of [1] says, Support of 802.3/Ethernet capabilities at the Packet Convergence Sublayer means Capability of classification and 802.3/Ethernet frames encapsulation into MAC SDUs ..... This implies that Ethernet CS does not emulate Ethernet like functionality and multicast/broadcast frames cannot be processed at the 802.16 MAC layer. These frames are sent to Ethernet Layer, which in turn may send to 802.16 MAC, to send out these multicast/broadcast frames there should be a downlink multicast/broadcast connection to which all MSs listening to. 2.2. IPv6 Convergence Sublayer 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 figures illustrate the typical network models for the IPv6 convergence sublayer. In this case, each MS may be on different IP link. +----+ +-------+ | MS |----------| BS/AR | +----+ +-------+ Figure 3 Madanapalli Expires June 2, 2006 [Page 5] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 +----+ +----+ +----+ | MS |----------| BS |----------| AR | +----+ +----+ +----+ _______________ ()_____________() Tunnel Figure 4 3. Problems 3.1. Root Causes The following are the three root problems that prevent running Neighbor Discovery protocol over 802.16 networks smoothly. The consequences of these characteristics are listed in Section [4]. 3.1.1. Multicast Support 802.16 is a connection oriented technology for the last mile supporting Point-to-multipoint architecture without bi-directional native multicast support. This prevents IPv6 nodes to multicast without explicit support on the network Side (e.g. Base Station). An MS can send a multicast packet to BS, however the processing rules at BS are similar to unicast packet i.e. BS may look at the classifiers and decide where to send the packet. Most of the Neighbor Discovery functionality depends on the multicast support from the lower layer. So for the Neighbor Discovery to function normally on MSs in 802.16 networks, there must some explicit support from the Network (e.g. Base Station). 802.16 provides support for Down-Link Multicast from Base Station to MSs . However each MS must listen on to the multicast CID to receive the packet. There can be multiple multicast addresses, each multicast address requires a multicast connection which my be difficult to set up and maintain. In [1], there is no mention about how a multicast packet/frame is processed at 802.16 MAC Layer. This leads to the following interpretation: When 802.16 MAC receives a Unicast/multicast/broadcast packet/Frame, from Upper Layers, it just looks at the various fields (classifiers) in the headers and maps to the outgoing CID (This can also be a Multicast CID in case of downlink). Madanapalli Expires June 2, 2006 [Page 6] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 When 802.16 MAC receives a packet/frame the PHY, it simply gives the packet/frame to the upper layers (Ethernet or IP). It is the upper layers responsibility to deliver the packet to the correct destination which nonetheless is limited by the existing of downlink multicast/broadcast connections for multicast/broadcast frames. The consequences of the lack of optimal multicast supports in 802.16 is that any IP layer protocol (e.g. IPv4 ARP, DHCPv4, IPv6 NDP, DHCPv6 etc.) that depends on the lower layer multicast support may not be able to function normally. 3.1.2. Subnet Model 802.16 connection oriented technology but the connection always ends at Base Station unlike in NBMA technologies (e.g. ATM and Frame Relay) where connections exist between peer entities. Because of this characteristic, So it is also unclear how two nodes connected to two different base stations communicate each other under the assumption that they are in same subnet. +-----+ +-----+ | MS1 |------+ +------| AR1 | +-----+ | | +-----+ | | | | | | +-----+ | +-----+ | +-----+ | MS2 |------+------| BS1 |------+------| AR2 | +-----+ +-----+ | +-----+ | | | +-----+ +-----+ | +-----+ | MS3 |-------------| BS2 |------+------| AR2 | +-----+ +-----+ +-----+ Figure 5 In case of IPv6 Convergence Sublayer, it is not clear whether an IP Packet will be terminated at Base Station or at Access Router. For the packet to be terminated at the Access Router, Base Station may need to use some sort of tunneling. If the packet terminates at BS, then the Base Station and Access Router should reside in same box. Depending on the use of Convergence Sublayer, prefix assignment and Madanapalli Expires June 2, 2006 [Page 7] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 the preference of operators, there can be three different types of subnet models. 1. The subnet consisting of multiple BSs and all the MSs hanging off them. 2. The subnet consisting of one BS and all the MSs hanging off it. 3. The subnet consisting of just the point to point connectivity between a BS or AR and one MS. 3.1.3. Transport Connection for IP Signaling Upon entering the network, the MS is assigned three management connections in each direction. These three connections reflect the three different QoS requirements used by different management levels. The first of these is the basic connection, which is used for the transfer of short, time-critical MAC and radio link control (RLC) messages. The primary management connection is used to transfer longer, more delay-tolerant messages such as those used for authentication and connection setup. The secondary management connection is used for the transfer of standards-based management messages such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network Management Protocol (SNMP). It is unclear whether the secondary management connection can be used for ICMP Messages. It may be that the MS is required to set up an initial transport connection for DAD for the link local address as well as for soliciting for Router Advertisements. Also, after a given time, there can be multiple connections between an MS and BS, so it is unclear which connection to use for the IP Signaling. 3.2. Problems with Neighbor Discovery over 802.16 3.2.1. Router Discovery Currently it is unclear when an MS need to solicit for Router Advertisements. To send an RS a transport connection is required. In general it is recommended that a host sends Router Solicitation when it receives a Link UP event from layer 2. But in case of 802.16 joining a Base Station may not trigger link up event as joining base station does not sufficient to send Layer 3 packet, it requires a transport connection to generate a link up event. For sending periodic Router Advertisements in 802.16 Networks, Base Station has no native support for sending this IP Packet to the MSs attached. The Base Station either needs to send the RA in Unicast Madanapalli Expires June 2, 2006 [Page 8] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 manner for each MS explicitly or send the RA in multicast connection slot. The latter approach needs a down link multicast connection to which all MSs should join to receive multicast packets. 3.2.2. Prefix Assignment Prefix Assignment may depend on the subnet model. If a unique prefix is assigned to each MS similar to 3G approach, then the subnet consists of only one MS in the subnet. If the same prefix is shared with multiple MSs then the subnet consists of multiple MSs. In this model an MS assumes that there exist on-link neighbors and tries to resolve the L2 address for the on-link prefixes. And direct communication using Link Layer Address between two MSs may not be possible. One way to overcome this problem is to advertise prefixes with L bit reset. 3.2.3. Address Autoconfiguration How Address Autoconfiguration can be achieved in 802.16 networks is dependent on following 1) Whether the MSs attached to the same BS are neighbors (Subnet Model), 2) Whether the prefix is being shared with other MSs. If a unique prefix is assigned to each MS similar to 3G approach, then the subnet consists of only one MS and hence duplicate address detection (DAD) is trivial. If the same prefix is shared with multiple MSs then the subnet consists of multiple MSs and DAD is required. DAD in 802.16 requires explicit multicast support from the Networks as there is no multicast support. This problem can be solved either Router/Base Station proxying for DAD on behalf of the address owners or Base Station supporting explicit multicast support. The former method reduces the amount of multicast traffic in the air but requires to maintain all the addresses that are currently in use. While configuring initial address ( i.e. Link Local address), the MS may need a transport connection for sending Neighbor Solicitation for address resolution. So MS may require establishing a connection for IP signaling. 3.2.4. Address Resolution Address Resolution is the process by which nodes determine the link- layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address. This means the Address Resolution entirely depends on the subnet model and convergence sublayer. In Madanapalli Expires June 2, 2006 [Page 9] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 case of IP CS, there is no need for Address Resolution as 802.16 MAC address is never used as part of the 802.16 Frame. In case of Ethernet CS, if the prefix is shared with L-bit set, the Address Resolution may be required, which in turn requires multicast support from 802.16MAC. 3.2.5. Neighbor Cache In 802.16 networks, the reachability may depend on the availability of a connection to BS. An MS establishes a connection to send packets with certain level of QoS to a particular destination. So to have an NC entry for a particular Neighbor, it may need to have a connection to BS for that neighbor. The other orthogonal issue is that the maintenance of neighbor cache for other MSs depends on the subnet model and whether there exists onlink prefixes. In case of IPv6 CS, the packet always goes to the AR (either co-located with BS or separate entity in which case BS needs to tunnel all the packets to AR) which implies there is no need for neighbor cache for other MSs. 3.2.6. Next-Hop Next-Hop Resolution may depend on the type of the convergence sublayer used. In case of Ethernet CS, Next-Hop Resolution can be performed as usual. In case of IPv6 CS, the Next-hop may always be an AR. 3.2.7. Neighbor Unreachability Detection (NUD) NUD depends on the subnet model as well Convergence Sublayer is used. In case of Ethernet CS, the NUD can be performed as usual. In case of IP CS, an MS may always see the AR as the next hop, the NUD is required only for the AR(s). Also the requirement of NUD may depend on the existence of a connection to the BS for that particular destination. If there exists multiple ARs (so default routers), it is unknown if the NUD is required if an AR is not serving any 802.16 MAC connection. 4. Goals The following are the goals in no particular order that point at relevant work to be done. Madanapalli Expires June 2, 2006 [Page 10] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 1. It is desirable to have a model for multicast/broadcast support in 802.16 so that an MS can send a multicast packet to all MSs within the Subnet. There should also be an option to turn off this facility in cases where it is not required or undesirable. 2. As many issues are dependent on the Subnet Model, it is desirable to develop a subnet model that is independent of the convergence sublayer. 3. It should be specified which connection (Secondary Management or a new IP signaling connection) an IPv6 enabled MS should use to send initial ICMP messages (e.g. DAD NS for link local address). 4. It is desirable to have a single solution that works independent of Convergence Sublayer being used. 5. The solution should work with the existing or normal IPv6 host implementations conforming to RFC 2461 and RFC 2462. 6. The solution should avoid using the air bandwidth wherever possible. 7. Existing solution must be used wherever possible. For example, if two MSs have connections to the same BS and can be viewed as two physical links; it should be studied if ND Proxy can be used in such cases if two MSs want communicate each other. 8. The solution should not introduce any new security threats. 9. As 802.16 network elements (BS and AR) are being developed newly, so it may be easier to introduce protocol/implementation changes for these elements instead of hosts, as hosts may be supporting multiple interfaces, so a single stack should work without any changes for all interfaces. 5. IANA Considerations There are no IANA considerations introduced by this draft. 6. Security Considerations This document provides the issues in running the IPv6 Neighbor Discovery over 802.16 networks, so this document as such does not introduce any security threats. However the solution based on the goals provided in this document may introduce security concerns which needs to be carefully analyzed before taking as part of the solution. 7. Acknowledgements The author would like to thank JinHyeock Choi, Erik Nordmark and Soohong D. Park for their feedback while writing this draft. Madanapalli Expires June 2, 2006 [Page 11] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 8. 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] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Madanapalli Expires June 2, 2006 [Page 12] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 Author's Address Syam Madanapalli Samsung ISO 3/1 Millers Road Bangalore-560 052, India Phone: +91 80 51197777 Email: syam@samsung.com Madanapalli Expires June 2, 2006 [Page 13] Internet-Draft IPv6 ND over 802.16: Problems and Goals November 2005 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 (2005). 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 Expires June 2, 2006 [Page 14]