Internet DRAFT - draft-madanapalli-ipv6-over-802.16-ipv6cs
draft-madanapalli-ipv6-over-802.16-ipv6cs
16ng Working Group S. Madanapalli
Internet-Draft Samsung ISO
Expires: December 16, 2006 B. Patil
Nokia
E. Nordmark
Sun Microsystems, Inc
J. Choi
Samsung AIT
S. Park
Samsung Electronics
June 14, 2006
Transmission of IPv6 over 802.16's IPv6 Convergence Sublayer
draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
IEEE 802.16d and 802.16e are air interface specifications for fixed
Madanapalli, et al. Expires December 16, 2006 [Page 1]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
and mobile broadband wireless access systems. 802.16d/e is the air
interface that is used in the WiMAX (Worldwide Interoperability of
Microwave Access) architecture and specified by the WiMAX forum.
This document defines the operation of IPv6 over the IPv6 convergence
sublayer of 802.16d/e within the scope of the WiMAX network
architecture. It specifies various aspects of IPv6 such as neighbor
discovery, address configuration, Path MTU and the transmission/
receiving of IPv6 packets.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of 802.16d/e Convergence Sublayer . . . . . . . . . . 3
2.1. IPv6 Service-Specific Convergence Sublayer Overview . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Architecture of WiMAX network . . . . . . . . . . . . . . . . 5
5. IPv6 Link model for IPv6 CS . . . . . . . . . . . . . . . . . 7
5.1. On-link communication . . . . . . . . . . . . . . . . . . 8
6. Transmission of IPv6 over 802.16d/e using IPv6 CS . . . . . . 8
6.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Maximum Transmission Unit . . . . . . . . . . . . . . . . 9
6.3. IPv6 Prefix Assignment . . . . . . . . . . . . . . . . . . 10
7. IPv6 Neighbor Discovery Procedures . . . . . . . . . . . . . . 10
7.1. Router Discovery . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. Router Solicitation . . . . . . . . . . . . . . . . . 10
7.1.2. Router Advertisement . . . . . . . . . . . . . . . . . 10
7.1.3. Router Lifetime and Periodic Router Advertisements . . 10
7.2. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 11
7.3. Address Resolution . . . . . . . . . . . . . . . . . . . . 11
7.4. Next-Hop Determination . . . . . . . . . . . . . . . . . . 11
7.5. Neighbor Unreachability Detection (NUD) . . . . . . . . . 11
8. Address Autoconfiguration . . . . . . . . . . . . . . . . . . 12
8.1. Stateless Address Autoconfiguration . . . . . . . . . . . 12
8.2. Stateful Address Autoconfiguration . . . . . . . . . . . . 12
9. Duplicate Address Detection . . . . . . . . . . . . . . . . . 12
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 13
9.2. Relay DAD Procedure . . . . . . . . . . . . . . . . . . . 13
9.2.1. MS Behavior . . . . . . . . . . . . . . . . . . . . . 15
9.2.2. AR Behavior . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Madanapalli, et al. Expires December 16, 2006 [Page 2]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
1. Introduction
IEEE 802.16d/e [1], [2] is the wireless MAN air interface standard.
802.16d/e specifications cover the PHY and MAC layers of the air
interface as well as the definition of several convergence sublayers
(CS) above the MAC which provide the capability for transmission of
ATM, IPv4/6, Ethernet and others. The network working group (NWG) in
WiMAX forum [11], which is an industry consortium, is specifying the
network architecture and documenting the operation of IPv4, IPv6 and,
Ethernet (802.3, 802.1q). The scope of this document is limited to
the specification of IPv6 over the IPv6 convergence sublayer of
802.16d/e.
This document specifies the link model in the context of the WiMAX
network architecture using the IEEE 802.16d/e air interface
specification as well as the operation of the various IPv6 features
such as Neighbor discovery, Address autoconfiguration, Path MTU among
others.
2. Overview of 802.16d/e Convergence Sublayer
The 802.16d/e MAC comprises of three sublayers:
- The service specific CS
- The MAC common part sublayer (CPS)
- The security sublayer
For details of the functionality of these sublayers, please refer to
the 802.16d/e specifications [1], [2].
Multiple CSs are provide for interfacing with various protocols. The
internal format of the CS is unique to the CS and the MAC CPS has no
necessity to understand or parse the CS payload. The service
specific CS resides above the MAC CPS and is responsible for
accepting and processing the higher layer PDUs (Packet Data Unit)
which includes classification of the higher layer PDUs and delivering
it to the appropriate MAC SAP (Service access point) and receiving
PDUs from the peer entity. The primary task of the convergence
sublayer is to classify service data units (SDUs) to the proper MAC
connection (CID).
Currently the two main CSs provided are: ATM CS and Packet CS.
Packet CS supports IEEE 802.3, IEEE 802.1Q, IPv4 and, IPv6 PDUs via
their own specific CS. Within the context of this document, IPv6 CS
is relevant.
Madanapalli, et al. Expires December 16, 2006 [Page 3]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
2.1. IPv6 Service-Specific Convergence Sublayer Overview
IPv6 CS is responsible for the transmission and reception of IPv6
packets. The IPv6 layer interfaces to the IPv6 CS as shown in the
figure below:
+-------------------+
| ULP |
+-------------------+
|
|
V
+-------------------+
| IPv6 |
+-------------------+
|
| MAC-SSCS SAP
V
+-------------------+
| 802.16 IPv6 CS |
+-------------------+
|
| MAC-CPS SAP
V
+-------------------+
| 802.16 MAC CPS |
+-------------------+
Figure 1. 802.16 MAC Sublayers
In case of IPv6 CS the classification parameters constitute of IPv6
Header and Transport Header. The following parameters are used as
classifiers in case of IPv6 CS: IPv6 source and destination
addresses, next header in the last header of the IP header chain,
Traffic Class, and, source and destination port numbers.
The following are the list of functions that IPv6 CS performs:
a. Classification of an IPv6 packet to an appropriate MAC Connection
b. Suppression of IPv6 Header, called Payload Header Suppression
(PHS) (optional)
c. Delivery of the resulting IPv6 CS PDU to the MAC-CPS SAP to
delivery to the peer MAC-CPS SAP.
d. Receipt of the IPv6 CS PDU from the MAC-CS SAP
Madanapalli, et al. Expires December 16, 2006 [Page 4]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
e. Rebuilding the IPv6 header if PHS is in use.
3. Terminology
Access Router (AR):
A layer 3 entity that acts as a first-hop default router for the
MSs. The WiMAX network architecture defines the concept of an
Access Service Network (ASN) which is a logical boundary and an
aggregation of functions. The ASN Gateway (ASN-GW) is a logical
entity that represents an aggregation of control plane functions
in addition to performing bearer plane routing or bridging
function. The IPv6 AR is a function of the ASN-GW when the base
station (BS) and ASN-GW are split and is a function of the ASN in
the case of an integrated entity which includes the BS and other
functions.
Base Station (BS):
A layer 2 entity conforming to 802.16 suite of standards that
transmit Layer 3 PDUs between MS and AR unchanged.
Convergence Sublayer (CS):
The service-specific convergence sublayers (called Convergence
Layers in this document) interfaces to higher layers, above the
core MAC common part sublayer. The primary task of the
convergence sublayer is to classify upper layer service data units
(SDUs) to the proper MAC connection.
Mobile Station (MS):
An end-user equipment that provides connectivity to 802.16 based
networks. The terms MS, SS (Subscriber Station) and host are used
interchangeably in this document.
Transport Connection:
An 802.16 based MAC connection between an MS and a BS with a
specific QoS attributes. There can be multiple connections
between an MS and a BS at any given time serving different QoS
requirements of the end user applications. Each connection is
identified by an unique identifier called Connection Identifier
(CID).
4. Architecture of WiMAX network
In WiMAX networks, ASN GW plays the role of Access Router (AR). An
MS is attached to only one ASN GW at a given time. ASN-GW manages
the information (including IP address) of all MSs on the link.
Subsequent to network entry, an MS is provided with an initial
Madanapalli, et al. Expires December 16, 2006 [Page 5]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
transport connection, Initial Service Flow, to communicate with the
AR to get the IP address and other host configuration information.
The following figures illustrates high level view of the elements in
the WiMAX network architecture that are involved in enabling IPv6:
+-----+
| MS1 |-----+
+-----+ |
|
|
+-----+ | +-----+ +-----------+
| MS2 |-----+-----| BS1 |----------| AR/ASN-GW |-----[Internet]
+-----+ | +-----+ +-----------+
. | ____________
. | ()__________()
+-----+ | L2 Tunnel
| MSn |-----+
+-----+
Figure 2. WiMAX N/W Architecture: Separate BS and AR
The above figure shows the case where BS and AR exist as separate
entities, in this case a tunnelled interface between the two exists.
+-----+
| MS1 |-----+
+-----+ |
|
|
+-----+ | +--------------+
| MS2 |-----+-------| BS/AR/ASN-GW |-----[Internet]
+-----+ | +--------------+
. |
. |
+-----+ |
| MSn |-----+
+-----+
Figure 3. WiMAX N/W Architecture: BS and AR in one box
Madanapalli, et al. Expires December 16, 2006 [Page 6]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
The above figure shows the case where BS and AR co-exist as a single
entity.
In either case, the AR is the first hop IPv6 Router for an MS/SS.
5. IPv6 Link model for IPv6 CS
The link between the MS and the AR at the IPv6 layer is viewed as a
shared link. The lower layer link between the MS and BS is a point-
to-point link. This point-to-point link between the MS and BS is
extended all the way to the AR when the granularity of the tunnel
between the BS and AR is on a per MS basis. However the tunneled
link between the BS and AR can also be a shared link which supports
multiple MSs. The lower-layer link between the MS and BS is referred
to as a MAC transport connection and is identified uniquely within
the scope of a BS by a Connection Identifier (CID). The figure below
shows the link model for IPv6:
MS
+----+ +----+
| | IPv6 (Shared link) | |
| L3 |=======================================| |
| | | |
|----| PTP conn. +----+ L2 Tunnel | AR |---[Internet]
| L2 |--------------| BS |===================| |
| | | | | |
+----+ +----+ | |
| |
+----+ L2 Tunnel | |
| BS |===================| |
| | | |
+----+ +----+
Figure 4. IPv6 link model in WiMAX Networks
An AR can serve one or more BSs. All MSs connected to BSs that are
served by an AR are on the same IPv6 link.
In the case of WiMAX, subsequent to the MS performing Registration
(an 802.16 procedure), there exists an initial L2 transport
connection between the MS and the AR which enables the sending and
receiving of IPv6 packets without any IPv6 address for the MS.
Madanapalli, et al. Expires December 16, 2006 [Page 7]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
5.1. On-link communication
The IPv6 link is a shared link. Hence from that perspective it
appears to an MS that it can reach any other MS on the same link
directly. However in reality the lower-layer is a point-to-point
link and all IPv6 packets between hosts that are on the same IPv6
link have to be transmitted via the AR. Packets originated by an MS
always are sent to the AR for delivery to a destination. When the
destination is another MS which is on the same IPv6 link, the AR
sends the packet unchanged to the destination MS, i.e. the AR does
not decrement the hop limit while forwarding the packet within the
link.
6. Transmission of IPv6 over 802.16d/e using IPv6 CS
IPv6 packets between the host/MS and BS are transmitted by
encapsulating the IPv6 packet in 802.16 frame with 6 octet MAC
header.
MS
+-------+
| UL |
|-------|
| IPv6 | BS
|-------| +-------+
|IPv6CS |--------//--------|IPv6CS |
|-------| 802.16d/e |-------|
| MAC | | MAC |
|-------| |-------|
| PHY | | PHY |
+-------+ +-------+
Figure 5. Transmission of IPv6 over IPv6 CS
6.1. Frame Format
IPv6 packets are transmitted in Generic 802.16 MAC frames as shown in
the following figure.
Madanapalli, et al. Expires December 16, 2006 [Page 8]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| Type |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) |
+-+-+-+-+-+-+-+-+
Figure 6. 802.16 Frame Format
H: Header Type (1 bit). Shall be set to zero indicating that it
is a Generic MAC PDU.
E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
is encrypted.
R: Reserved. Shall be set to zero.
C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
EKS: Encryption Key Sequence
LEN: The Length in bytes of the MAC PDU including the MAC header
and the CRC if present (11 bits)
CID: Connection Identifier (16 bits)
HCS: Header Check Sequence (8 bits)
CRC: An optional 8-bit field. CRC appended to the PDU after
encryption.
Type: This field indicates the subheaders (Mesh subheader,
Fragmentation Subheader, Packing subheader etc and special payload
types (ARQ) present in the message payload
6.2. Maximum Transmission Unit
The 802.16d/e link has an MTU of 1522 octets. Hence the MTU of the
IPv6 packets can be configured to be 1500 octets as the
recommendation in [3]. However because of a tunnelled interface
between the BS and the Access router (AR), it makes sense to limit
Madanapalli, et al. Expires December 16, 2006 [Page 9]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
the MTU to a value less than 1500 octets. A value of 1400 octets is
recommended for the MTU on the IPv6 hosts. Router advertisements can
however override the recommended MTU and specify an appropriate value
which is 1500 octets or less.
6.3. IPv6 Prefix Assignment
The IPv6 link between MSs and the AR is a shared link. An IPv6
prefix is shared by all the nodes which are on the same link. The
prefix is assigned to the nodes with On-link flag (L-flag) reset so
that the nodes may not make on-link assumption for the addresses
whose prefix matches with sending node prefix.
7. IPv6 Neighbor Discovery Procedures
7.1. Router Discovery
7.1.1. Router Solicitation
An MS can send a Router Solicitation message to solicit a Router
Advertisement message from the AR to acquire necessary information as
specified in [4]. On completion of the network attachment procedure
(802.16 specific), an initial transport connection is established
between the MS and the AR. The MS should send a router solicitation
as soon as this connection is established. An MS that is network
attached may also send router solicitations at any time.
7.1.2. Router Advertisement
Upon receiving a Router Solicitation or as soon as the initial
transport connection following the network attachment procedure is
established, the AR sends a router advertisement. As there is only
one AR at any given time serving an MS which receives a Router
Solicitation from an MS, the Router Advertisement can be sent without
any random delay.
AR may send unsolicited Router Advertisements periodically as
specified in [4].
7.1.3. Router Lifetime and Periodic Router Advertisements
The router lifetime should be set to a large value, preferably in
hours. 802.16d/e hosts have the capability to transition to an Idle
mode in which case the radio link between the BS and MS is torn down.
Paging is required in case the network needs to deliver packets to
the MS. In order to avoid waking a mobile which is in Idle mode and
consuming resources on the air interface, the interval between
Madanapalli, et al. Expires December 16, 2006 [Page 10]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
periodic router advertisements should be set quite high. The
MaxRtrAdvInterval should be configurable to a value which is greater
than 1800 seconds and less than 14400 seconds.
7.2. Prefix Discovery
The AR advertises the prefixes by putting PIO (Prefix Information
Option) in the Router Advertisements and an MS learns the prefix
information by consulting these PIOs. The prefixes are advertised
with on-link flag (L-bit) reset so that the MSs may not make any
assumption about existence of on-link neighbors. In PIO, a prefix
may be advertised with autonomous address-configuration flag (A-bit)
set. The MSs on the link uses the prefix with A-bit set for auto-
configuring an IPv6 address in a stateless manner as specified in
[5]. All Router Advertisements should contain all the prefixes
assigned to the IPv6 link. To enable this, the link should not be
assigned with too many prefixes so that all the PIOs can be sent in a
single Router Advertisement.
7.3. Address Resolution
When IPv6 is supported over the IPv6 CS in the case of 802.16d/e, the
IPv6 layer sits directly over the 802.16d/e MAC layer. The MAC
address of the host is not used in the MAC header. Instead a
Connection Identifier (CID) is used. As s result address resolution
is not required in this case.
However an MS or an AR may perform address resolution if they have
been implemented as per IPv6 suite of specifications. In such cases
the AR can relay the address resolution request to the MS that is
owning the target IPv6 address so that the actual MS responds to the
address resolution query. An intelligent/future implementation may
choose not to do the address resolution if the access technology is
802.16d/e with IPv6 CS.
7.4. Next-Hop Determination
The Next-hop for an MS is always the AR and so Next-Hop resolution
may be trivial. An intelligent/future implementation of a host may
choose not to do the next-hop determination if the access technology
is 802.16d/e.
7.5. Neighbor Unreachability Detection (NUD)
For an MS the only neighbor is the AR and hence the MS can avoid the
NUD which can be derived from the MAC layer functionality e.g.
existence of a MAC transport connection. However the AR must perform
NUD as defined in [4] using NS/NA exchange as the MS may have
Madanapalli, et al. Expires December 16, 2006 [Page 11]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
multiple addresses at any given time.
8. Address Autoconfiguration
MSs can configure their addresses using either stateless address
autoconfiguration or stateful configuration with DHCPv6.
8.1. Stateless Address Autoconfiguration
Stateless address autoconfiguration is performed as specified in [5].
The Interface Identifier is generated from its MAC address as per
[6]. The MS may also generate random Interface Identifiers as per
the privacy extensions specification for address autoconfiguration as
per [7]. The address configured through stateless address
autoconfiguration must pass the duplicate address detection test
before being assigned to the interface.
8.2. Stateful Address Autoconfiguration
The Stateful Address Autoconfiguration is invoked if the M-flag is
set in the Router Advertisement. Obtaining the IPv6 address through
stateful address autoconfiguration method is specified in the [8].
The address configured through stateful address autoconfiguration
must pass the duplicate address detection test before being assigned
to the interface.
9. Duplicate Address Detection
The IPv6 link is viewed as a shared link. However the DAD procedure
as specified in [5] does not adapt well to the 802.16d/e air
interface. In order to optimize the air interface and to conserve
the battery life of MSs that are in Idle mode, it is not recommended
to multicast the NS messages to all hosts on the link. An
enhancement to the DAD mechanism is specified here for use in the
case of IPv6 over 802.16d/e.
The WiMAX IPv6 AR is aware of all the IPv6 addresses configured by
the hosts for which it is the serving AR. When an MS initiates the
DAD procedure by sending a DAD NS, the AR looks at its authoritative
address cache to determine if the target address in DAD NS is a
duplicate. If a match exists, the AR relays the DAD NS to the MS
that currently is configured with that address. The MS which owns
the address defends the address as specified in [5] by sending a DAD
NA which is relayed via the AR to the MS performing the DAD
procedure.
Madanapalli, et al. Expires December 16, 2006 [Page 12]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
9.1. Conceptual Data Structures
In order to enable Relay DAD, the AR needs to maintain the following
information for each interface.
Authoritative Address Cache:
A set of entries about the IPv6 addresses that are currently in
use by the MSs belonging to the same IPv6 link as the router
interface. The authoritative address Cache includes all types of
addresses (link local, unique local and global addresses). The AR
learns the addresses from the DAD Neighbor Solicitation and
updates the address cache. The entries in the Authoritative
Address Cache are deleted only if the prefix lifetime expires or
the node deregisters explicitly. The link local addresses have
infinite lifetime and will be deleted only when there is an
explicit deregistration of the particular MS
The deregistration procedure is specific to 802.16d/e and the
interaction between the deregistration procedure and the deletion
of the address from the authoritative address cache is outside the
scope of this document.
9.2. Relay DAD Procedure
The following figure illustrates the Relay DAD procedures.
Madanapalli, et al. Expires December 16, 2006 [Page 13]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
+-------+ +-------+ +-------+
| MS1 | | BS/AR | | MS2 |
+-------+ +-------+ +-------+
| | |
| N/W Entry & Auth | |
(1) |<--------------------->| |
| | |
| Transport conn. Est. | |
(2) |<--------------------->| |
| | |
| | |
|LLA Construction | |
(3) |------+ | |
| | | |
|<-----+ | |
| | |
| MLD Join | |
(4) |---------------------->| |
| | |
| DAD NS | |
(5) |---------------------->| |
| |Addr. Cache Lookup |
(6) | |------+ |
| | | |
| |<-----+ |
| | |
| | DAD NS |
(7) | |---------------------->|
| | |
| DAD NA | |
(8) |<----------------------|<----------------------|
| | |
| | |
Figure 7. Relay DAD
1. The MS1 performs initial network entry and authentication
procedures as described in 802.16d/e
2. On successful completion of step 1, an initial transport
connection is established between the MS and the AR.
3. MS1 constructs a Link Local Address as specified in [5].
4. MS1 constructs a solicited node multicast address for the
corresponding Link Local Address and sends MLD Join request for
the solicited node multicast address.
Madanapalli, et al. Expires December 16, 2006 [Page 14]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
5. MS1 starts verifying address uniqueness by sending a DAD NS on
the initial MAC transport connection. The MS1 can also send a
Router Solicitation simultaneously on initial MAC transport
connection for Router and Prefix discovery.
6. AR looks into the authoritative address cache to check if the
address is already in use
7. AR relays the DAD NS to the address owner (MS2) in case there is
match in the address cache.
8. MS2 defends the address by sending DAD NA, which is relayed to
MS1 via the AR. Upon on receiving the DAD NA, it discards the
tentative address and behaves as specified in [5].
9.2.1. MS Behavior
The MS behavior is as specified in [5]. And it is recommended that
the MS performs DAD for all addresses that it acquires before
assigning to its interface even if the same Interface Identifier
being reused for the new address.
9.2.2. AR Behavior
The AR must implement the address cache and must not decrement the
hop limit while forwarding the DAD NS to the address owner. An
address that matches with the interface identifier (least 64 bits)
must be considered as duplicate as some implementations may choose
not to do DAD for all addresses constructed from the same interface
identifier. If the MS which owns the address is in idle mode, the MS
must be paged and brought to active state in order to deliver the DAD
NS.
The AR also required to maintain the state (MS information) for all
DAD NSs that it relays, so that the DAD NA can be relayed back the
DAD probing MS.
10. IANA Considerations
This draft does not require any actions from IANA.
11. Security Considerations
This document specifies the operation of IPv6 over the IEEE 802.16d/e
air interface and hence the security aspects are equivalent to the
IPv6 specifications.
The IPv6 AR in the case of 802.16d/e maintains the addresses of all
the hosts that it is currently serving. As a result a couple of
Madanapalli, et al. Expires December 16, 2006 [Page 15]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
issues arise:
1. A malicious node may launch a DoS attack by configuring a large
number of addresses and performing DAD on those. However this is not
an issue since the AR is aware at the lower layer the identity of the
host performing the DAD and has the ability to terminate the
connection.
2. A malicious node may configure a large number of addresses and
attempt to insert these in the AR's address cache. This may result
in an overflow of the address cache at the AR. It is recommended
that hosts in such a network be allowed to configure a limited number
of addresses. This number is a configurable parameter and is
implementation specific to the AR.
12. Acknowledgements
TBD
13. References
[1] "IEEE 802.16d, IEEE standard for Local and metropolitan area
networks, Part 16:Air Interface for fixed broadband wireless
access systems", October 2004.
[2] "IEEE 802.16e, IEEE standard for Local and metropolitan area
networks, Part 16:Air Interface for fixed and Mobile broadband
wireless access systems", October 2005.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Madanapalli, et al. Expires December 16, 2006 [Page 16]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
[9] Madanapalli, S., "IPv6 Neighbor Discovery over 802.16: Problems
and Goals,
draft-madanapalli-nd-over-802.16-problems-00.txt(work in
progress)", November 2005.
[10] Bernard, B., "Multiple Encapsulation Methods Considered
Harmful, draft-iab-link-encaps-00.txt (work in progress)",
May 2006.
[11] "WiMAX Forum, www.wimaxforum.org".
Madanapalli, et al. Expires December 16, 2006 [Page 17]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
Authors' Addresses
Syam Madanapalli
Samsung ISO
66/1 Bagmane Tech Park
CV Raman Nagar
Bangalore 560093
India
Phone: +91-80-41819999
Email: smadanapalli at gmail dot com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
US
Email: basavaraj.patil@nokia.com
Erik Nordmark
Sun Microsystems, Inc
901 San Antonio Road
Palo Alto, CA 94110
US
Email: erik.nordmark@sun.com
JinHyeock Choi
Samsung AIT
Communication Lab
P.O.Box 111
Suwon 440-600
Korea
Phone: +82-31-280-9233
Email: jinchoe@samsung.com
Madanapalli, et al. Expires December 16, 2006 [Page 18]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
Soohong D. Park
Samsung Electronics
Mobile Platform Laboratory
416, Maetan-3dong, Yeongtong-Gu
Suwon
Korea
Phone: +82-31-200-4508
Email: soohong.park@samsung.com
Madanapalli, et al. Expires December 16, 2006 [Page 19]
Internet-Draft IPv6 over 802.16's IPv6 CS June 2006
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 procedures with respect to rights in RFC 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
Copyright (C) The Internet Society (2006). 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.
Madanapalli, et al. Expires December 16, 2006 [Page 20]
