IPv6 WG S. Daniel Park Internet Draft S. Madanapalli Expires : August 2004 O.L.N. Rao SAMSUNG February 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. 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. Park, Syam, OLN Informational [Page 1] Internet Draft IPv6 Packets over WiFi February 2004 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 Same as described in [IPv6oE]. 3. Frame Format Same as described in [IPv6oE]. 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 Duplicate Address Detection 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 Park, Syam, OLN Informational [Page 2] Internet Draft IPv6 Packets over WiFi February 2004 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 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. Park, Syam, OLN Informational [Page 3] Internet Draft IPv6 Packets over WiFi February 2004 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 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 Same as described in [IPv6oE]. 6. Address Mapping -- Unicast Same as described in [IPv6oE]. 7. Address Mapping -- Multicast Same as described in [IPv6oE]. Park, Syam, OLN Informational [Page 4] Internet Draft IPv6 Packets over WiFi February 2004 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. 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 [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. Park, Syam, OLN Informational [Page 5] Internet Draft IPv6 Packets over WiFi February 2004 Authors' Addresses Soohong Daniel Park, Mobile Platform Laboratory, SAMSUNG Electronics, Korea Phone: +82 31 200 4508 EMail: Soohong.Park@samsung.com O.L.N.Rao, Network Systems Division, Samsung India Software Operations, 3/1, JP Techno Parks, Millers Road, Bangalore - 560 052 Phone: +91 80 51197777 EMail: OLNRao@samsung.com Syam Madanapalli, Network Systems Division, Samsung India Software Operations, 3/1, JP Techno Parks, Millers Road, Bangalore - 560 052 Phone: +91 80 51197777 EMail: Syam@samsung.com Park, Syam, OLN Informational [Page 6] Internet Draft IPv6 Packets over WiFi February 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 Informational [Page 7] Internet Draft IPv6 Packets over WiFi February 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 Informational [Page 8]