One document matched: draft-park-ipv6-dad-problem-wlan-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 17:55:29 |