IPv6 Working Group S. Daniel Park Internet-Draft Syam Madanapalli Expires : January 8, 2004 O.L.N. Rao Filename: draft-park-ipv6-dad-problem-wlan-00.txt SAMSUNG July 9, 2003 IPv6 DAD Consideration for 802.11 Environment 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 (2003). All Rights Reserved, Abstract This memo tries to consider a problem when IPv6 node performs DAD procedure to verify address duplication in 802.11 [WLAN] environment. Park, et. al. Expires January 8, 2004 [Page 1]
Internet-Draft IPv6 DAD for 802.11 July 9, 2003 Table of Contents 1. Introduction 1.1 Terminology 2. Problem Statement for IPv6 DAD in 802.11 3. Solution Considerations 3.1. Existing Solutions 3.2. Some Possible Solutions 4. Security Consideration 5. References 6. Authors' Addresses 7. Full Copyright Statement 1. Introduction In order to generate unique address, an IPv6 nodes has to perform DAD (Duplicate Address Detection) procedure when the IPv6 node tries to make its own IPv6 address including link-local and global address. If IPv6 node detects address duplication by Neighbor Advertisement message from duplicated node, then the duplicated address can not be used for this node, then IPv6 node MUST generate its own address by other mechanism like DHCP or Random Interface ID generation etc. Generally, address duplication is happened to the same Interface ID which is composed of 48bit/64bit MAC address. Therefore, when same MAC address is existed in the same link, one of these nodes can not make its IPv6 address using address autoconfiguration mechanism. However, if the same MAC address is existed in the same link as 802.11, there are some problems and considerations for IPv6 address autoconfiguration. IPv6 node in 802.11 environment will never be able to receive the DAD packets if its MAC address is same as another node, because of the frame filtering based on the source MAC address. In this case the DAD always succeeds even though the addresses are duplicate. This memo tries to consider above problem and suggest possible solutions. Note that this consideration SHOULD be discussed at the IPv6 node requirements [NODEREQ]. 1.1 Terminology 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 RFC 2119 [2119]. Park, et. al. Expires January 8, 2004 [Page 2]
Internet-Draft IPv6 DAD for 802.11 July 9, 2003 2. Problem Statement for IPv6 DAD in 802.11 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." As we saw 802.11 spec [WLAN], the 802.11 standard says to discard the frame if the source MAC address matches with its own MAC address. When an 802.11 end station sends a broadcast frame, the access point sends the frame to the originator also. So the originator of the broadcast frame SHOULD discard it by matching with the source MAC address. In this case, IPv6 DAD will not be able to detect duplicate address in 802.11 environment because if am 802.11 end station recevies a DAD packet from a node which is having same MAC, the 802.11 end station discards the frame and will not be able to defend the DAD. So the DAD always succeeds even though there are two end stations with the same MAC address. Consequently, IPv6 node generates its address without any duplication, but this address is not unique address but duplicated address. This concludes that "Multicast Packet Filtering based on Source Address" makes "Duplicate Address Detection" procedure trivial. Park, et. al. Expires January 8, 2004 [Page 3]
Internet-Draft IPv6 DAD for 802.11 July 9, 2003 3. Solution Considerations In this section, we explore the existing solutions and the limitations, and possible solutions. 3.1. Existing Solutions RFC 1112 [1112], 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. Appendix A of RFC 2462: "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 interface's multicast loopback semantics, and the interface cannot discard received packets simply because the source link-layer address is the same as the interfaces." " This particular problem can be avoided by temporarily disabling the software suppression of loopbacks while a node performs Duplicate Address Detection." Even this solution does not work as a node can never know when the other node that has got same MAC address starts "Duplicate Address Detection". As 802.11 end station filters packet based on source MAC address, the node can not defend DAD. In this case, the DAD always succeeds even though this node has got the same address. 3.2. Some Possible Solutions Enhanced Multicast Filtering at Layer 2 In this case, Station is required to maintain the State information for Broacast and Multicast frames sent at Layer 2. In this case the node that is originating the frame can discard the frames based on the state information rather than source address alone. Selective Filtering at Layer 2 In this case, Station is required not to filter the DAD packets. At layer 3, IPv6 decides to process this DAD packet dependin upon wethere this node has sent this DAD packet or some other node with the same MAC address has sent this DAD packet. Park, et. al. Expires January 8, 2004 [Page 4]
Internet-Draft IPv6 DAD for 802.11 July 9, 2003 4. Security Consideration This memo does not affect the security of the Internet, but implementations of IPv6 are expected to support a minimum set of security features to ensure security on the Internet. [NODEREQ] 5. References [2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [WLAN] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition. [2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration" RFC 2462 December 1998. [1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112 August 1989. [NODEREQ] J. Loughney, "IPv6 Node Requirements", Internet-Draft, (work in progress), June 2003. 6. Authors' Addresses Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. Email:Soohong.Park@samsung.com Syam Madanapalli Network Systems Division, SAMSUNG India Software Operations, INDIA Email:syam@samsung.com O.L.N. Rao Network Systems Division, SAMSUNG India Software Operations, INDIA Phone: +91-80-51197777 Email:olnrao@samsung.com Park, et. al. Expires January 8, 2004 [Page 5]
Internet-Draft IPv6 DAD for 802.11 July 9, 2003 7. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. 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. Park, et. al. Expires January 8, 2004 [Page 6]