Internet Engineering Task Force S. Daniel Park (Ed.) Internet Draft Samsung Electronics Expires : October 20, 2004 S. Madanapalli O.L.N. Rao Samsung ISO April 21, 2004 Transmission of IPv6 Packets over WiFi Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the transmission of IPv6 packets over IEEE 802.11 specification called WiFi and several considerations. Park, Syam, OLN Expires: October 20, 2004 [Page 1] Internet Draft IPv6 Packets over WiFi April 21, 2004 1. Introduction WiFi networks use radio technologies defined by IEEE in 802.11x to provide secure, reliable, fast wireless connectivity. A WiFi network 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 WiFi networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [NDP] when the messages are transmitted over WiFi network. 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]. 2. Maximum Transmission Unit The term WiFi includes CSMA/CA based on 802.11 specifications with various data rates in wireless environment. Otherwise it is same as described in [IPv6oE]. 3. Frame Format IPv6 packets are transmitted in standard 802.11 frames. The WiFi 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 WiFi wireless link. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration/ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Park, Syam, OLN Expires: October 20, 2004 [Page 2] Internet Draft IPv6 Packets over WiFi April 21, 2004 | Destination | +- -+ | Address | +- -+ | (Address1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +- -+ | Address | +- -+ | (Address2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver | +- -+ | Address | +- -+ | (Address3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmitter | +- -+ | Address | +- -+ | (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.) Park, Syam, OLN Expires: October 20, 2004 [Page 3] Internet Draft IPv6 Packets over WiFi April 21, 2004 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 WiFi 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 In WiFi 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 Park, Syam, OLN Expires: October 20, 2004 [Page 4] Internet Draft IPv6 Packets over WiFi April 21, 2004 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 WiFi Networks One way of solving this problem is to permanently disable the "Source based multicast packet filtering" by L2 and L3 has to 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 Park, Syam, OLN Expires: October 20, 2004 [Page 5] Internet Draft IPv6 Packets over WiFi April 21, 2004 may not be supported by all the hardware implementations. Second, the WiFi 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 WiFi networks. 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 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. In this case the originating station receives only its DAD packets and other packets get filtered at layer 2 as usual. 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an WiFi 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 WiFi link- layer addresses is described in [NDP]. The Source/Target Link-layer Address option has the following form when the link layer is WiFi. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- WiFi -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Park, Syam, OLN Expires: October 20, 2004 [Page 6] Internet Draft IPv6 Packets over WiFi April 21, 2004 Option fields: Type: 1 for Source Link-layer address. 2 for Target Link-layer address. Length: 1 (in units of 8 octets). WiFi Address: The 48 bit WiFi IEEE 802 address, in canonical it 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 WiFi frame may contain up to four address field 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 WiFi 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 [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html Park, Syam, OLN Expires: October 20, 2004 [Page 7] Internet Draft IPv6 Packets over WiFi April 21, 2004 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [IPv6oE] Crawford M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, 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. [WLAN] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Computer Society, ANSI/IEEE 802.11, 1999 Edition. [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Park, Syam, OLN Expires: October 20, 2004 [Page 8] Internet Draft IPv6 Packets over WiFi April 21, 2004 10. Authors' Addresses Soohong Daniel Park (Editor) Samsung Electronics Korea Phone: +82 31 200 4508 EMail: Soohong.Park@samsung.com Syam Madanapalli O.L.N.Rao Samsung India Software Operations Samsung India Software Operations India India Phone: +91 80 51197777 Phone: +91 80 51197777 EMail: Syam@samsung.com EMail: OLNRao@samsung.com 11. Acknowledgements Specially thanks to Matt Crawford for his valuable contributions on the [IPv6oE] as author. Park, Syam, OLN Expires: October 20, 2004 [Page 9] Internet Draft IPv6 Packets over WiFi April 21, 2004 12. Appendix A This section describes the addressing and related bits of WiFi 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 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. Park, Syam, OLN Expires: October 20, 2004 [Page 10] Internet Draft IPv6 Packets over WiFi April 21, 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Park, Syam, OLN Expires: October 20, 2004 [Page 11] Internet Draft IPv6 Packets over WiFi April 21, 2004 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Park, Syam, OLN Expires: October 20, 2004 [Page 12]