Internet-Draft S. Daniel Park (Ed.) July 19, 2004 Samsung Electronics S. Madanapalli O.L.N. Rao Samsung ISO Transmission of IPv6 Packets over 802.11/WLAN Networks Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the transmission of IPv6 packets over WLAN with several considerations such as stateless address autoconfiguration (i.e., forming addresses and DAD issue), NDP Source and Target Link Layer Address Option formats and etc. Park (Editor) Expires: January 18, 2005 [Page 1] Internet Draft IPv6 Packets over WLAN July 19, 2004 1. Introduction WLANs use radio technologies defined by IEEE in 802.11x to provide secure, reliable, fast wireless connectivity. A WLAN can be used to connect computers to each other, to the Internet, and to Wired Ethernet Networks. This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses, statelessly autoconfigured addresses and Duplicate Address Detection (DAD) procedures on WLANs. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [NDP] when the messages are transmitted over WLAN. Several appendixes are described in this document. This document provides reference to [IPv6oE] wherever applicable. 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 [KEYWORDS]. The term WLAN includes CSMA/CA based on IEEE 802.11 specifications with various data rates in wireless environment. Otherwise it is same as described in [IPv6oE]. 2. Maximum Transmission Unit Most [WLAN] implementations register themselves as 802.3 media to OS. Hence, the default MTU size for IPv6 [IPV6] packets on a WLAN is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on a WLAN interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. Nonetheless note that WLAN provides a greater MTU than the Park (Editor) Expires: January 18, 2005 [Page 2] Internet Draft IPv6 Packets over WLAN July 19, 2004 Ethernet. Hence, it is recommended to use the MTU provided by L2 driver if available than this default MTU. 3. Frame Format IPv6 packets are transmitted in standard 802.11 frames. The WLAN header contains the 24 or 30 octets MAC headers, 6 octets SNAP header and the Type code, which must contain the value 0x86DD hexadecimal. The data field contains the IPv6 header followed immediately by the payload, and possibly padding octets to meet the minimum frame size for the WLAN. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration/ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +- -+ | Address | +- -+ | (Address1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +- -+ | Address | +- -+ | (Address2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver | +- -+ | Address | +- -+ | (Address3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmitter | +- -+ | Address | Park (Editor) Expires: January 18, 2005 [Page 3] Internet Draft IPv6 Packets over WLAN July 19, 2004 +- -+ | (Address4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SNAP | +- -+ | header | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one bit.) Note: for more detailed description of the frame fields, refer to Section 7: Frame Formats of [WLAN]. Most transmissions use three addresses (Destination, Source and Receiver), which is why only three of the four addresses are contiguous in the frame format. The transmitter address is used only in wireless bridging. 4. Stateless Autoconfiguration The Interface Identifier [AARCH] for a WLAN interface is based on the EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE 802 address. Forming of EUI64 is same as described in [IPv6oE]. 4.1 DAD Considerations Park (Editor) Expires: January 18, 2005 [Page 4] Internet Draft IPv6 Packets over WLAN July 19, 2004 In WLAN networks, IPv6 DAD defined in [ACONF] will not work because of the Source Address Based Packet Filtering at layer 2. The following are the snips from different standards. Appendix A of RFC 2462 [ACONF] states: To perform Duplicate Address Detection correctly in the case where two interfaces are using the same link-layer address, an implementation MUST have a good understanding of the interfaces multicast loopback semantics, and the interface cannot discard received packets simply because the source link-layer address is the same as the interface. RFC 1112 [MCAST], introducer of multicast concept, states: Recommends that the service interface provide a way for an upper- layer protocol to inhibit local delivery of packets sent to a multicast group that the sending host is a member of. 9.2.7 Section of WLAN Specification 802.11 [WLAN] states: The STA originating the message SHALL receive the message as a broadcast/multicast message. Therefore, all STAs SHALL filter out broadcast/multicast messages that contain their address as the source address. The above statements conclude that "Multicast Packet Filtering based on Source Address" is a MUST. So, all DAD-NS (Neighbor Solicitation) & DAD-NA (Neighbor Advertisement) packets gets filtered at L2 and L3 does not get the DAD packets from the other node with the same MAC address. Hence, "Duplicate Address Detection" always succeeds even though there are two end stations with the same MAC address. 4.1.1 DAD Procedures in WLANs One way of solving this problem is to permanently disable the "Source based multicast packet filtering" by L2 and L3 has to Park (Editor) Expires: January 18, 2005 [Page 5] Internet Draft IPv6 Packets over WLAN July 19, 2004 process all the packets and do filtering at L3. In this case, the DAD originating STA gets its own DAD packets and DAD always fails. So a node running Duplicate Address Detection must maintain the count of the number of Neighbor Solicitations the node has sent and the number of Neighbor Solicitations received for a tentative address and compares them. If there is a mismatch and the number of Neighbor Solicitations received is more than the sent then the tentative address is a duplicate. When a node sends out a DAD packet note down the control information such as Target address, DAD send counter, and DAD receive counter. Target Address = Address for which DAD is performed DAD Send Counter = No. of DAD-NS sent for Target DAD Recv Counter = No. of DAD-NS received for Target When ever a node sends out a DAD packet DAD-Send counter is incremented for that target. Similarly, whenever a node receives a DAD packet DAD-Receive counter is incremented. Whenever DAD-Recv counter becomes greater than DAD-Sent counter, the node can conclude that the DAD has failed. Also, when DAD-Sent counter reaches DupAddrTransmits and DAD Wait timer times out, node can conclude that the DAD has succeeded and the address is unique. However the above solution has two limitations. One, it requires L2 support for disabling source address based packet filtering which may not be supported by all the hardware implementations. Second, the WLAN end station will receive all the packets that it originates, this may require substantial processing at layer 3. To overcome these issues, the following DAD procedure is recommended in WLANs. Whenever a node sends DAD packet (i.e. DAD-NS or DAD-NA), it MUST send the packet with Unspecified (all zeros) Source Address in Layer Park (Editor) Expires: January 18, 2005 [Page 6] Internet Draft IPv6 Packets over WLAN July 19, 2004 2 Header field so that it will not be filtered at L2 and rest of the procedure for Duplicate Address Detection is same as above. 5. Link-Local Addresses The IPv6 link-local address [AARCH] for a WLAN interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ 6. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into WLAN link- layer addresses is described in [NDP]. The Source/Target Link-layer Address option has the following form when the link layer is WLAN. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- WLAN -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option fields: o Type: 1 for Source Link-layer address. 2 for Target Link-layer address. o Length: 1 (in units of 8 octets). Park (Editor) Expires: January 18, 2005 [Page 7] Internet Draft IPv6 Packets over WLAN July 19, 2004 o WLAN Address: The 48 bit WLAN address, in canonical order. This is the address the interface currently responds to, and may be different from the built-in address used to derive the Interface Identifier. As described in section 3, the WLAN frame may contain up to four address fields and both Destination address (DA) and Source address (SA) are only used for address mapping of unicast. (Refer to Appendix A) 7. Address Mapping -- Multicast Addressing in WLAN follows the conventions used for the other IEEE 802 networks, including Ethernet. Addresses are 48 bits long. When the first bit is a 1, the address represents a group of physical stations and is called a multicast address, thus all IPv6 multicast addresses MUST be mapped to this address. Address1 is only used for multicast address. 8. Security Considerations The method of derivation of Interface Identifiers from MAC addresses is intended to preserve global uniqueness when possible. However, there is no protection from duplication through accident or forgery. 9. References 9.1 Normative References [WLAN] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Computer Society, ANSI/IEEE 802.11, 1999 Edition. [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [IPv6oE] Crawford M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. Park (Editor) Expires: January 18, 2005 [Page 8] Internet Draft IPv6 Packets over WLAN July 19, 2004 9.2 Informative References [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [NDP] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [PROCESS] Bradner, S., "The Internet Standards Process", BCP 9, RFC 2026, October 1996. [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 10. Authors' Addresses Soohong Daniel Park (Editor) Samsung Electronics Korea Phone: +82 31 200 4508 Email: Soohong.Park@samsung.com Syam Madanapalli Samsung India Software Operations India Phone: +91 80 51197777 Email: Syam@samsung.com O.L.N. Rao Samsung India Software Operations India Phone: +91 80 51197777 Email: OLNRao@samsung.com Park (Editor) Expires: January 18, 2005 [Page 9] Internet Draft IPv6 Packets over WLAN July 19, 2004 11. Acknowledgements Specially thanks to Matt Crawford for his valuable contributions on the [IPv6oE] as author. Thanks to the IPv6 mailing list participants for the thread with subject WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server). Thanks Bernard Aboba for his valuable comments and feedbacks. 12. Appendix A This section describes the addressing and related bits of WLAN frame format. The number and function of the address fields depends on which of the distribution system (DS) bits are set, so the use of the address fields indirectly depends on the type of network deployed. Below table summarizes the use of the address fields in date frames. Function ToDS FromDS Address1 Address2 Address3 Address4 ================================================================= IBSS 0 0 DA SA BSSID not used ----------------------------------------------------------------- To AP 1 0 BSSID SA DA not used ----------------------------------------------------------------- From AP 0 1 DA BSSID SA not used ----------------------------------------------------------------- WDS(bridge) 1 1 RA TA DA SA ================================================================= Description: Both To AP and From AP are only used for infrastructure mode. DA: Destination Address SA: Source Address RA: Receiver Address TA: Transmitter Address BSSID: Basic Service Set ID IBSS: Independent BSS WDS: Wireless Distribution System Park (Editor) Expires: January 18, 2005 [Page 10] Internet Draft IPv6 Packets over WLAN July 19, 2004 For easy understanding, below description is cited from the [NDP] The Source Link-Layer Address option: contains the link-layer address of the sender of the packet. It is used in the Neighbor Solicitation, Router Solicitation, and Router Advertisement packets. The Target Link-Layer Address option: contains the link-layer address of the target. It is used in Neighbor Advertisement and Redirect packets. 13. Appendix B Configurable Parameters and Recommended Values The values given here are just recommended. A more detailed study of the real time environment values and analysis fetches a better set of values. NDP and AUTOCONF Configuration Parameters DupAddrDetectTransmits: 3 retransmissions RETRANS_TIMER: Having this fixed MAY not be good for Wireless networks. It is recommended to have the RETRANS_TIMER as varying and fine tuned to the real time environment using standard Retransmission Tuning Algorithms. MAX_MULTICAST_SOLICIT 5 transmissions MAX_UNICAST_SOLICIT 5 transmissions MAX_ANYCAST_DELAY_TIME 2 second MAX_NEIGHBOR_ADVERTISEMENT 5 transmissions REACHABLE_TIME 20,000 milliseconds Park (Editor) Expires: January 18, 2005 [Page 11] Internet Draft IPv6 Packets over WLAN July 19, 2004 RETRANS_TIMER see above DELAY_FIRST_PROBE_TIME 5 seconds MIN_RANDOM_FACTOR .5 MAX_RANDOM_FACTOR 1.5 14. Appendix C This section describes different issues and concerns running IPv6 over WLAN. As per the specification of WLAN multicast upstream transmission (STA to AP) is reliable. But, multicast downstream transmission (AP to STA) is not. As, the multicast upstream frames get an ACK but multicast downstream frames do not. Also, broadcast and multicast are nothing but the same for WLAN. And, hence there might be difficulties in sending multicast packets (e.g. ND messages) over lossy WLAN links. Also, emulating WLAN as Ethernet to L3 is a big problem for MIPv6 as it can not utilize L2 intelligence. TODO: - Optimize ND for WLAN; do not kill ND just for WLAN problems. - Analyze the behavior of an implementation of WLAN not emulated as Ethernet - Optimize Autoconfiguration for WLAN; Autoconfiguration should be treated differently from ND even though they use the same messages - Think of recommendations to IEEE for better L2-and-L3 inter working. - Can Proxy ND by AP, on behalf of its associated nodes, solve the problem ? - Analyze the usage of Solicited Node Multicast vs Broadcast usage in WLAN in terms of the performance over head for STAs against the reliability of message transmission with such address. Park (Editor) Expires: January 18, 2005 [Page 12] Internet Draft IPv6 Packets over WLAN July 19, 2004 - Can we recommend Radio Layer 2.5 work to align for solving these issues with out changing L2 and L3 standards. 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 IETF's procedures with respect to rights in IETF 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 Park (Editor) Expires: January 18, 2005 [Page 13] Internet Draft IPv6 Packets over WLAN July 19, 2004 Copyright (C) The Internet Society (2004). 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. Park (Editor) Expires: January 18, 2005 [Page 14]