Network Working Group Basavaraj Patil
Internet-Draft Nokia
Intended status: Standards Track Frank Xia
Expires: September 6, 2007 Behcet Sarikaya
Huawei USA
JH. Choi
Samsung AIT
Syam Madanapalli
LogicaCMG
March 5, 2007
IPv6 Over the IP Specific part of the Packet Convergence sublayer in
802.16 Networks
draft-ietf-16ng-ipv6-over-ipv6cs-08
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 September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
IEEE Std 802.16 is an Air Interface for Fixed and Mobile Broadband
Patil, et al. Expires September 6, 2007 [Page 1]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Wireless Access Systems. The 802.16 specification includes several
service specific convergence sublayers (CS) as part of the MAC
(Medium Access Control) layer which are used by upper layer
protocols. The ATM CS and Packet CS are the two main service
specific convergence sublayers and these are a part of the 802.16 MAC
to which the upper layers interface. The packet CS is used for
transport for all packet-based protocols such as Internet Protocol
(IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP
specific part of the Packet CS enables transport of IPv4 and IPv6
packets directly over the MAC. This document specifies the
addressing and operation of IPv6 over the IP specific part of the
packet CS for hosts served by a network that utilizes the IEEE Std
802.16 air interface. It recommends the assignment of a unique
prefix (or prefixes) to each host and allows the host to use multiple
identifiers within that prefix, including support for randomly
generated interface identifiers.
Patil, et al. Expires September 6, 2007 [Page 2]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IEEE 802.16 convergence sublayer support for IPv6 . . . . . . 5
4.1. IPv6 encapsulation over the IP CS of the MAC . . . . . . . 7
5. Generic network architecture using the 802.16 air interface . 9
6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 10
6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 11
6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 12
7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 12
8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 12
8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 13
8.3. Router lifetime and periodic router advertisements . . . . 13
9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 13
9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 13
9.2. Duplicate address detection . . . . . . . . . . . . . . . 14
9.3. Stateless address autoconfiguration . . . . . . . . . . . 14
9.4. Stateful address autoconfiguration . . . . . . . . . . . . 14
10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. WiMAX network architecture and IPv6 support . . . . . 16
Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 18
Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 19
Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Patil, et al. Expires September 6, 2007 [Page 3]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
1. Conventions used in this document
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 [RFC2119].
2. Introduction
IEEE 802.16e is an air interface for fixed and mobile broadband
wireless access systems. Orthogonal Frequency Division Multiplexing
(OFDM) is the basis of the air interface. The standard specifies the
air interface, including the medium access control (MAC) layer and
multiple physical layer (PHY) specifications. It can be deployed in
licensed as well as unlicensed spectrum. While the PHY and MAC are
specified in IEEE 802.16, the details of IPv4 and IPv6 operation over
the air interface are not included. This document specifies the
operation of IPv6 over the IEEE 802.16 air interface.
IPv6 packets can be carried over the IEEE Std 802.16 specified air
interface via :
1. the IP specific part of the Packet CS or,
2. the 802.3 specific part of the Packet CS or,
3. the 802.1Q specific part of the Packet CS.
The 802.16 [802.16] specification includes the Phy and MAC details.
The convergence sublayers are a part of the MAC. This document
specifies IPv6 from the perspective of the transmission of IPv6 over
the IP specific part of the packet convergence sublayer.
The mobile station/host is attached to an access router via a base
station (BS). The host and the BS are connected via the IEEE Std
802.16 air interface at the link and physical layers. The IPv6 link
from the MS terminates at an access router which may be a part of the
BS or an entity beyond the BS. The base station is a layer 2 entity
(from the perspective of the IPv6 link between the MS and AR) and
relays the IPv6 packets between the AR and the host via a point-to-
point connection over the air interface.
3. Terminology
The terminology in this document is based on the definitions in
[PSDOC].
Patil, et al. Expires September 6, 2007 [Page 4]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
4. IEEE 802.16 convergence sublayer support for IPv6
The IEEE 802.16 MAC specifies two main service specific convergence
sublayers:
1. ATM Convergence sublayer
2. Packet Convergence sublayer
The Packet CS is used for the transport of packet based protocols
which include:
1. IEEE Std 802.3(Ethernet)
2. IEEE Std 802.1Q(VLAN)
3. Internet Protocol (IPv4 and IPv6)
The service specific CS resides on top of the MAC Common Part
Sublayer (CPS). The service specific CS is responsible for:
o accepting packets (PDUs) from the upper layer,
o performing classification of the packet/PDU based on a set of
classifiers that are defined which are service specific,
o delivering the CS PDU to the appropriate service flow and
transport connection and,
o receiving PDUs from the peer entity.
Payload header suppression (PHS) is also a function of the CS but is
optional.
The figure below shows the concept of the service specific CS in
relation to the MAC:
-----------------------------\
| ATM CS | Packet CS | \
----------------------------- \
| MAC Common Part Sublayer | \
| (Ranging, scheduling, etc)| 802.16 MAC
----------------------------- /
| Security | /
|(Auth, encryption,key mgmt)| /
-----------------------------/
| PHY |
-----------------------------
Figure 1: The 802.16 MAC
Patil, et al. Expires September 6, 2007 [Page 5]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Classifiers for each of the specific upper-layer protocols, i.e
Ethernet, VLAN and IP, are defined in the IEEE 802.16 specification,
which enable the packets from the upper layer to be processed by the
appropriate service specific part of the packet CS. IPv6 can be
transported directly over the IP specific part of the packet CS or
over 802.3/Ethernet (which in turn is handled by the Ethernet
specific part of the packet CS) or over 802.1Q (which is handled by
the 802.1Q specific part of the packet CS). IPv6 over the IP
specific part of the packet CS SHOULD be the default method for IPv6
packet transmission. IPv4 packets also are transported over the IP
specific part of the packet CS. The classifiers enable the
differntiation of IPv4 and IPv6 packets and mapping to specific
transport connections over the air-interface.
The figure below shows the options for IPv6 transport over the packet
CS of 802.16:
----------------- -----------------
| IPv6 | | IPv6 |
---------------- |---------------| |----------- |
| IPv6 | | Ethernet | | 802.1Q |
|--------------| |---------------| |----------- |
| IP Specific | | 802.3 specific| |802.1Q specific|
|part of Pkt CS| |part of Pkt CS | |part of Pkt CS |
|..............| |...............| |...............|
| MAC | | MAC | | MAC |
|--------------| |---------------| |---------------|
| PHY | | PHY | | PHY |
---------------- ----------------- -----------------
(1) IPv6 over (2) IPv6 over (3) IPv6 over
IP Specific part 802.3/Ethernet 802.1Q
of Packet CS
Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet
CS
The scope of this document is limited to IPv6 operation over the IP
specific part of the Packet CS only. IPv4 over the IP specific part
of the packet CS is specified in [IPv4CS]. It should be noted that
immediately after ranging (802.16 air interface procedure), the MS
and BS exchange their capability negotiation via REG-REQ
(Registration Request) and REG-RSP (Registration Response) 802.16 MAC
messages. These management frames negotiate parameters such as the
Patil, et al. Expires September 6, 2007 [Page 6]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Convergence Sublayer support. By default, Packet, IPv4 and 802.3/
Ethernet are supported. IPv6 via the Packet CS is supported by the
MS and the BS only when the IPv6 support bit in the capability
negotiation messages (REG-REQ and REG-RSP) implying such support is
indicated in the parameter "Classification/PHS options and SDU
(Service Data Unit) encapsulation support" (Refer to [802.16]).
Additionally during the establishment of the transport connection for
transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition) and
DSA-RSP messages between the BS and MS indicate via the CS-
Specification TLV the CS that the connection being setup shall use.
When the IPv6 packet is preceded by the 802.16 six byte MAC header
there is no specific indication in the MAC header itself about the
payload type. The processing of the packet is based entirely on the
classifiers. Based on the classification rules, the MAC layer
selects an appropriate transport connection for the transmission of
the packet. An IPv6 packet is transported over a transport
connection that is specifically established for carrying such
packets.
Transmission of IPv6 as explained above is possible via multiple
methods, i.e, via the IP specific part of the packet CS or via
Ethernet or 802.1Q interfaces. The choice of which method to use is
implementation specific. When IPv6 is carried via the IP convergence
sublayer, this specification SHOULD be followd. In order to ensure
interoperability the BS SHOULD support the IP specific part of the
packet CS and the Ethernet specific part of the packet CS for IPv6
transport. Hosts which may implement one or the other method for
transmission would be assured of the ability to establish a transport
connection that would enable the transport of IPv6 packets.
Inability to negotiate a common convergence sublayer for the
transport connection between the MS and BS will result in failure to
setup the transport connection and thereby render the host unable to
send and receive IPv6 packets. In the case of a host which
implements more than one method of transporting IPv6 packets, the
choice of which method to use (i.e IPv6 over the IP specific part of
the packet CS or IPv6 over 802.3 or, IPv6 over 802.1Q) is
implementation specific. The host and the BS SHOULD support the
transmission of IPv6 over the IP specific part of the packet
convergence sublayer. The default method for IPv6 packet
transmission over 802.16 should be via the packet CS.
4.1. IPv6 encapsulation over the IP CS of the MAC
The IPv6 payload when carried over the IP specific part of the Packet
CS is encapsulated by the 6 byte 802.16 generic MAC header. The
format of the IPv6 packet encapsulated by the generic MAC header is
shown in the figure below. The format of the 6 byte MAC header is
described in the [802.16] specification. The CRC (cyclic redundancy
Patil, et al. Expires September 6, 2007 [Page 7]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
check) is optional. It should be noted that the actual MAC address
is not included in the MAC header.
---------/ /-----------
| MAC SDU |
--------/ /------------
||
||
MSB \/ LSB
---------------------------------------------------------
| Generic MAC header| IPv6 Payload | CRC |
---------------------------------------------------------
Figure 3: IPv6 encapsulation
For transmission of IPv6 packets via the IP specific part of the
Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC
directly. The IPv6 layer delivers the IPv6 packet to the Packet CS
of the 802.16. The packet CS defines a set of classifiers that are
used to determine how to handle the packet. The IP classifiers that
are used at the MAC operate on the fields of the IP header and the
transport protocol and these include the IP Traffic class, Next
header field, Masked IP source and destination addresses and,
Protocol source and destination port ranges. Next header in this
case refers to the last header of the IP header chain. Using the
classifiers, the MAC maps an upper layer packet to a specific service
flow and transport connection to be used. The MAC encapsulates the
IPv6 packet in the 6 byte MAC header (MAC SDU) and transmits it. The
figure below shows the operation on the downlink, i.e the
transmission from the BS to the host. The reverse is applicable for
the uplink transmission.
Patil, et al. Expires September 6, 2007 [Page 8]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
----------- ----------
| IPv6 Pkt| |IPv6 Pkt|
----------- ----------
| | /|\
| | |
--[SAP]--------------------- ---------[SAP]--------
||-| |----------| | | /|\ |
|| \ / 0---->[CID1] | | --- |-------- |
|| Downlink 0\/-->[CID2] | | |Reconstruct| |
|| classifiers0/\-->[....] | | | (undo PHS)| |
|| 0---->[CIDn] | | --- ------- |
||--------------| | | /|\ |
| | | | |
| {SDU, CID,..} | | {SDU, CID,..} |
| | | | /|\ |
| v | | | |
------[SAP]----------------- |-------[SAP]---------
| 802.16 MAC CPS |------>| 802.16 MAC CPS |
---------------------------- ----------------------
Figure 4: IPv6 packet transmission: Downlink
5. Generic network architecture using the 802.16 air interface
In a network that utilizes the 802.16 air interface the host/MS is
attached to an IPv6 access router (AR) in the network. The BS is a
layer 2 entity only. The AR can be an integral part of the BS or the
AR could be an entity beyond the BS within the access network. IPv6
packets between the MS and BS are carried over a point-to-point
transport connection which has a unique connection identifier (CID).
The transport connection is a MAC layer link between the MS and the
BS. The figures below describe the possible network architectures
and are generic in nature. More esoteric architectures are possible
but not considered in the scope of this document. Option A:
+-----+ CID1 +--------------+
| MS1 |------------/| BS/AR |-----[Internet]
+-----+ / +--------------+
. /---/
. CIDn
+-----+ /
| MSn |---/
+-----+
Patil, et al. Expires September 6, 2007 [Page 9]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Figure 5: The IPv6 AR as an integral part of the BS
Option B:
+-----+ CID1 +-----+ +-----------+
| MS1 |----------/| BS1 |----------| AR |-----[Internet]
+-----+ / +-----+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
Figure 6: The IPv6 AR is separate from the BS
The above network models serve as examples and are shown to
illustrate the point to point link between the MS and the AR.
6. IPv6 link
RFC 2461 defines link as a communication facility or medium over
which nodes can communicate at the link layer, i.e., the layer
immediately below IP [RFC2461]. A link is bounded by routers that
decrement the Hop limit field in the IPv6 header. When an MS moves
within a link, it can keep using its IP addresses. This is a layer 3
definition and note that the definition is not identical with the
definition of the term '(L2) link' in IEEE 802 standards.
6.1. IPv6 link in 802.16
In 802.16, the Transport Connection between an MS and a BS is used to
transport user data, i.e. IPv6 packets in this case. A Transport
Connection is represented by a CID (Connection Identifier) and
multiple Transport Connections can exist between an MS and BS.
When an AR and a BS are collocated, the collection of Transport
Connections to an MS is defined as a single link. When an AR and a
BS are separated, it is recommended that a tunnel is established
between the AR and a BS whose granuality is no greater than 'per MS'
or 'per service flow' ( An MS can have multiple service flows which
are identified by a service flow ID). Then the tunnel(s) for an MS,
in combination with the MS's Transport connections, forms a single
point-to-point link.
Patil, et al. Expires September 6, 2007 [Page 10]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
The collection of service flows (tunnels) to an MS is defined as a
single link. Each link has only an MS and an AR. Each MS belongs to
a different link. A different prefix should be assigned to each
unique link. This link is fully consistent with a standard IP link,
without exception and conforms with the definition of a point-to-
point link in RFC2461 [RFC2461]. Hence the point-to-point link model
for IPv6 operation over the IP specific part of the Packet CS in
802.16 SHOULD be used. A unique IPv6 prefix(es) per link (MS/host)
MUST be assigned.
6.2. IPv6 link establishment in 802.16
In order to enable the sending and receiving of IPv6 packets between
the MS and the AR, the link between the MS and the AR via the BS
needs to be established. This section illustrates the link
establishment procedure.
The MS goes through the network entry procedure as specified by
802.16. A high level description of the network entry procedure is
as follows:
1. MS performs initial ranging with the BS. Ranging is a process by
which an MS becomes time aligned with the BS. The MS is
synchronized with the BS at the succesful completion of ranging
and is ready to setup a connection.
2. MS and BS perform capability exchange as per 802.16 procedures.
The CS capability parameter indicates which classification/PHS
options and SDU encapsulation the MS supports. By default,
Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence
of this parameter in REG-REQ (802.16 message) means that named
options are supported by the MS/SS. Support for IPv6 over the IP
specific part of the packet CS is indicated by Bit#2 of the CS
capability parameter (Refer to [802.16]).
3. The MS progresses to an authentication phase. Authentication is
based on PKMv2 as defined in the IEEE Std 802.16 specification.
4. On succesful completion of authentication, the MS performs 802.16
registration with the network.
5. The MS MUST request the establishment of a service flow for IPv6
packets over the IP specific part of the Packet CS. The service
flow MAY also be triggered by the network as a result of pre-
provisioning. The service flow establishes a link between the MS
and the AR over which IPv6 packets can be sent and received.
6. The AR and MS should send router advertisements and solicitations
as specified in Neighbor discovery, RFC2461 [RFC2461].
The above flow does not show the actual 802.16 messages that are used
for ranging, capability exchange or service flow establishment.
Details of these are in [802.16].
Patil, et al. Expires September 6, 2007 [Page 11]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
6.3. Maximum transmission unit in 802.16
The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte
header followed by an optional payload and an optional CRC covering
the header and the payload. The length of the PDU is indicated by
the Len parameter in the Generic MAC Header. The Len parameter has a
size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6
payload can be a max value of 2038 bytes ( Total PDU size minus (MAC
Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038
bytes and the minimum value of 1280 bytes. The default MTU for IPv6
over 802.16 SHOULD be the same as specified in RFC2460 which is 1500
octets. RFC2461 defines an MTU option that an AR can advertise to an
MN. If an AR advertises an MTU via the RA MTU option, the MN SHOULD
use the MTU from the RA.
7. IPv6 prefix assignment
The MS and the AR are connected via a point-to-point connection at
the IPv6 layer. Hence each MS can be considered to be on a separate
subnet. A CPE (Customer Premise Equipment) type of device which
serves multiple IPv6 hosts, may be the end point of the connection.
Hence one or more /64 prefixes SHOULD be assigned to a link. The
prefixes are advertised with the on-link (L-bit) flag set as
specified in RFC2461 [RFC2461]. The size and number of the prefixes
is a configuration issue. Also, prefix delegation MAY be used to
provide additional prefixes for a router connected over 802.16. The
other properties of the prefixes are also dealt via configuration.
8. Router Discovery
8.1. Router Solicitation
On completion of the establishment of the IPv6 link, the MS may send
a router solicitation message to solicit a Router Advertisement
message from the AR to acquire necessary information as per RFC2461.
An MS that is network attached may also send router solicitations at
any time as per RFC2461. Movement detection at the IP layer of an MS
in many cases is based on receiving periodic router advertisements.
An MS may also detect changes in its attachment via link triggers or
other means. The MS can act on such triggers by sending router
solicitations. The router solicitation is sent over the IPv6 link
that has been previously established. The MS sends router
solicitations to the all-routers multicast address. It is carried
over the point-to-point link to the AR via the BS. The MS does not
need to be aware of the link-local address of the AR in order to send
a router solicitation at any time.
Patil, et al. Expires September 6, 2007 [Page 12]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
8.2. Router Advertisement
The AR should send a number (configurable value) of router
advertisements as soon as the IPv6 link is established, to the MS.
The AR sends unsolicited router advertisements periodically as per
RFC2461. The interval between periodic router advertisements is
however greater than the specification in RFC2461 and is discussed in
the following section.
8.3. Router lifetime and periodic router advertisements
The router lifetime SHOULD be set to a large value, preferably in
hours. This document over-rides the specification for the value of
the router lifetime in Neighbor Discovery for IP Version 6 (IPv6)
RFC2461 [RFC2461]. The AdvDefaultLifetime in the router
advertisement MUST be either zero or between MaxRtrAdvInterval and
43200 seconds. The default value is 2 * MaxRtrAdvInterval.
802.16 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 periodic router
advertisements SHOULD be set quite high. The MaxRtrAdvInterval value
specified in this document over-rides the recommendation in Neighbor
Discovery for IP Version 6 (IPv6) RFC2461 [RFC2461]. The
MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than
21600 seconds. The default value for MaxRtrAdvInterval is 10800
seconds.
9. IPv6 addressing for hosts
The addressing scheme for IPv6 hosts in 802.16 network follows the
IETFs recommendation for hosts specified in IPv6 Node Requirement,
RFC 4294. The IPv6 node requirements RFC4294 [RFC4294] specifies a
set of RFCs that are applicable for addressing and the same is
applicable for hosts that use 802.16 as the link layer for
transporting IPv6 packets.
9.1. Interface Identifier
The MS has a 48-bit MAC address as specified in 802.16 [802.16].
This MAC address MUST be used if EUI-64 based interface identifier is
needed for autoconfiguration, IP Version 6 Addressing Architecture
RFC4291 [RFC4291]. As in other links that support IPv6, EUI-64 based
interface identifiers are not mandatory and other mechanisms, such as
random interface identifiers, Privacy Extensions for Stateless
Patil, et al. Expires September 6, 2007 [Page 13]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Address Autoconfiguration in IPv6 RFC3041 [RFC3041] MAY also be used.
9.2. Duplicate address detection
DAD SHOULD be performed as per Neighbor Discovery for IP Version
6,RFC2461 [RFC2461] and, IPv6 Stateless Address Autoconfiguration,
RFC2462 [RFC2462]. It MAY be redundant to perform DAD on a global
unicast address that is configured using the EUI-64 or generated as
per RFC3041 [RFC3041] for the interface as part of the IPv6 stateless
address autoconfiguration protocol RFC2462 [RFC2462] as long as the
following two conditions are met:
1. The prefixes advertised through the router advertisement messages
by the access router terminating the 802.16 IPv6 link is unique
to that link.
2. The access router terminating the 802.16 IPv6 link does not
autoconfigure any IPv6 global unicast addresses from the prefix
that it advertises.
9.3. Stateless address autoconfiguration
If the A-bit in the prefix information option (PIO) is set, the MS
SHOULD perform stateless address autoconfiguration as per RFC 2461,
2462. The AR is the default router that advertises a unique prefix
(or prefixes) that is used by the MS to configure an address.
9.4. 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 RFC3315
[RFC3315]. The MS MUST obtain an address via the stateful address
autoconfiguration mechanism when the M-flag is set in the router
advertisement.
10. Multicast Listener Discovery
Multicast Listener Discovery Version 2(MLDv2) for IPv6 RFC3810
[RFC3810] SHOULD be supported as specified by the hosts and routers
attached to each other via an 802.16 link. The access router which
has hosts attached to it via a Point-to-point link over an 802.16
SHOULD not send periodic queries if the host is in idle/dormant mode.
The AR can obtain information about the state of a host from the
paging controller in the network.
Patil, et al. Expires September 6, 2007 [Page 14]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
11. IANA Considerations
This draft does not require any actions from IANA.
12. Security Considerations
This document does not introduce any new vulnerabilities to IPv6
specifications or operation. The security of the 802.16 air
interface is the subject of [802.16]. In addition, the security
issues of the network architecture spanning beyond the 802.16 base
stations is the subject of the documents defining such architectures,
such as WiMAX Network Architecture [WiMAXArch].
13. Acknowledgments
The authors would like to acknowledge the contributions of the 16NG
working group chairs Soohong Daniel Park and Gabriel Montenegro as
well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ
Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret
Wasserman and Pekka Savola for their review and comments.
14. References
14.1. Normative References
[802.16] "IEEE Std 802.16e: IEEE Standard for Local and
metropolitan area networks, Amendment for Physical and
Medium Access Control Layers for Combined Fixed and Mobile
Operation in Licensed Bands", October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119>.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2462>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3810>.
Patil, et al. Expires September 6, 2007 [Page 15]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006,
<ftp://ftp.isi.edu/in-notes/rfc4291>.
14.2. Informative References
[IPv4CS] Madanapalli, S. and S. Park, "Transmission of IPv4 packets
over 802.16's IP Convergence Sublayer", February 2007, <ht
tp://www.ietf.org/internet-drafts/
draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt>.
[PSDOC] Jee, J., Madanapalli, S., Montenegro, G., Riegel, M.,
Mandin, J., and S. Park, "IP over 802.16 Problem Statement
and Goals", October 2006, <http://www.ietf.org/
internet-drafts/draft-ietf-16ng-ps-goals-00.txt>.
[RFC3041] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", August 2006, <http://www.ietf.org/internet-drafts/
draft-ietf-ipv6-privacy-addrs-v2-05.txt>.
[RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003,
<ftp://ftp.isi.edu/in-notes/rfc3315>.
[RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
April 2006, <ftp://ftp.isi.edu/in-notes/rfc4294>.
[WMF] "http://www.wimaxforum.org".
[WiMAXArch]
"WiMAX End-to-End Network Systems Architecture
http://www.wimaxforum.org/technology/documents",
August 2006.
Appendix A. WiMAX network architecture and IPv6 support
The WiMAX (Worldwide Interoperability for Microwave Access) forum
[WMF] has defined a network architecture in which the air interface
is based on the IEEE 802.16 standard. The addressing and operation
of IPv6 described in this document is applicable to the WiMAX network
as well.
The WiMAX network architecture consists of the Access Service Network
(ASN) and the Connectivity Service Network (CSN). The ASN is the
access network which includes the BS and the AR in addition to other
Patil, et al. Expires September 6, 2007 [Page 16]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
functions such as AAA, Mobile IP Foreign agent, Paging controller,
Location Register etc. The ASN is defined as a complete set of
network functions needed to provide radio access to a WiMAX
subscriber. The ASN is the access network to which the MS attaches.
The IPv6 access router is an entity within the ASN. The term ASN is
specific to the WiMAX network architecture. The CSN is the entity
that provides connectivity to the Internet and includes functions
such as Mobile IP Home agent and AAA. The figure below shows the
WiMAX reference model:
-------------------
| ---- ASN | |----|
---- | |BS|\ R6 -------| |---------| | CSN|
|MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | |
---- | |R8 /--|------|----| |-----|Home|
| ---- / | | visited| | NSP|
| |BS|/ | | NSP | | |
| ---- | |---------| | |
| NAP | \ |----|
------------------- \---| /
| | /
| (--|------/----)
|R4 ( )
| ( ASP network )
--------- ( or Internet )
| ASN | ( )
--------- (----------)
Figure 7: WiMAX Network reference model
Three different types of ASN realizations called profiles are defined
by the architecture. ASNs of profile types A and C include BS' and
ASN-gateway(s) (ASN-GW) which are connected to each other via an R6
interface. An ASN of profile type B is one in which the
functionality of the BS and other ASN functions are merged together.
No ASN-GW is specifically defined in a profile B ASN. The absence of
the R6 interface is also a profile B specific characteristic. The MS
at the IPv6 layer is associated with the AR in the ASN. The AR may
be a function of the ASN-GW in the case of profiles A and C and is a
function in the ASN in the case of profile B. When the BS and the AR
are separate entities and linked via the R6 interface, IPv6 packets
between the BS and the AR are carried over a GRE tunnel. The
granularity of the GRE tunnel should be on a per MS basis or on a per
service flow basis (an MS can have multiple service flows, each of
Patil, et al. Expires September 6, 2007 [Page 17]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
which are identified uniquely by a service flow ID). The protocol
stack in WiMAX for IPv6 is shown below:
|-------|
| App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| |
|-------| /------ -------
| | / IPv6 | | |
| IPv6 |- - - - - - - - - - - - - - - - / | | |-->
| | --------------- -------/ | | IPv6|
|-------| | \Relay/ | | | |- - - | |
| | | \ / | | GRE | | | |
| | | \ /GRE | - | | | | |
| |- - - | |-----| |------| | | |
| IPv6CS| |IPv6CS | IP | - | IP | | | |
| ..... | |...... |-----| |------|--------| |-----|
| MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 |
|-------| |------ |-----| |----- |--------| |-----|
| PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 |
-------- --------------- ----------------- -------
MS BS AR/ASN-GW CSN Rtr
Figure 8: WiMAX protocol stack
As can be seen from the protocol stack description, the IPv6 end-
points are constituted in the MS and the AR. The BS provides lower
layer connectivity for the IPv6 link.
Appendix B. IPv6 link in WiMAX
WiMAX is an example of a network based on the IEEE Std 802.16 air
interface. This section describes the IPv6 link in the context of a
WiMAX network. The MS and the AR are connected via a combination of
:
1. The transport connection which is identified by a Connection
Identifier (CID) over the air interface, i.e the MS and BS and,
2. A GRE tunnel between the BS and AR which transports the IPv6
packets
From an IPv6 perspective the MS and the AR are connected by a point-
to-point link. The combination of transport connection over the air
interface and the GRE tunnel between the BS and AR creates a (point-
Patil, et al. Expires September 6, 2007 [Page 18]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
to-point) tunnel at the layer below IPv6.
The collection of service flows (tunnels) to an MS is defined as a
single link. Each link has only an MS and an AR. Each MS belongs to
a different link. No two MSs belong to the same link. A different
prefix should be assigned to each unique link. This link is fully
consistent with a standard IP link, without exception and conforms
with the definition of a point-to-point link in RFC2461 [RFC2461].
Appendix C. IPv6 link establishment in WiMAX
The mobile station performs initial network entry as specified in
802.16. On succesful completion of the network entry procedure the
ASN gateway/AR triggers the establishment of the initial service flow
(ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the
ASN-GW/AR and the BS. The BS in turn requests the MS to establish a
transport connection over the air interface. The end result is a
transport connection over the air interface for carrying IPv6 packets
and a GRE tunnel between the BS and AR for relaying the IPv6 packets.
On succesful completion of the establishment of the ISF, IPv6 packets
can be sent and received between the MS and AR. The ISF enables the
MS to communicate with the AR for host configuration procedures.
After the establishment of the ISF, the AR can send a router
advertisement to the MS. An MS can establish multiple service flows
with different QoS characteristics. The ISF can be considered as the
primary service flow. The ASN-GW/ AR treats each ISF, along with the
other service flows to the same MS, as a unique link which is managed
as a (virtual) interface.
Appendix D. Maximum transmission unit in WiMAX
The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
Hence the IPv6 path MTU can be 1500 octets. However because of the
overhead of the GRE tunnel used to transport IPv6 packets between the
BS and AR and the 6 byte MAC header over the air interface, using a
value of 1500 would result in fragmentation of packets. It is
recommended that the default MTU for IPv6 be set to 1400 octets for
the MS in WiMAX networks. Note that the 1522 octet specification is
a WiMAX forum specification and not the size of the SDU that can be
transmitted over 802.16, which has a higher limit.
Patil, et al. Expires September 6, 2007 [Page 19]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Authors' Addresses
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Email: sarikaya@ieee.org
JinHyeock Choi
Samsung AIT
Networking Technology Lab
P.O.Box 111
Suwon, Korea 440-600
Email: jinchoe@samsung.com
Syam Madanapalli
LogicaCMG
125 Yemlur P.O.
Off Airport Road
Bangalore, India 560037
Email: smadanapalli@gmail.com
Patil, et al. Expires September 6, 2007 [Page 20]
Internet-Draft IPv6 over Packet CS in 802.16 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Patil, et al. Expires September 6, 2007 [Page 21]
