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
<draft-daniel-ipv6-over-wifi-01.txt>
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]