Network Working Group Basavaraj. Patil
Internet-Draft Nokia
Intended status: Standards Track Frank. Xia
Expires: April 17, 2007 Behcet. Sarikaya
Huawei USA
Syam. Madanapalli
LogicaCMG
JinHyeock. Choi
Samsung AIT
October 14, 2006
IPv6 Over IPv6 Convergence sublayer in WiMAX Networks
draft-ietf-16ng-ipv6-over-ipv6cs-00
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 April 17, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Patil, et al. Expires April 17, 2007 [Page 1]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
Abstract
The WiMAX forum is defining the network architecture which enables
Internet connectivity to mobile stations and IP hosts via the
802.16d/e radio interface. This document specifies the addressing
and operation of IPv6 for hosts served by a WiMAX network. It
recommends the assignment of a unique prefix to each host and allow
the host to use multiple identifiers within that prefix, including
support for randomly generated identifiers. IPv6 operation in WiMAX
networks as explained in this document is based entirely on existing
IETF specifications. The solution entailed herein is recommended for
adoption by the WiMAX forum for IPv6 over the IPv6 convergence
sublayer.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IEEE 802.16d/e convergence sublayer support for IPv6 . . . . . 6
5. WiMAX network architecture . . . . . . . . . . . . . . . . . . 7
6. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . . . . . . 9
6.1. IPv6 link establishment . . . . . . . . . . . . . . . . . 9
6.2. Maximum transmission unit . . . . . . . . . . . . . . . . 9
7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 11
8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Router Solictation . . . . . . . . . . . . . . . . . . . . 12
8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 12
8.3. Router lifetime and periodic router advertisements . . . . 12
9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 13
9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 13
9.2. Duplicate address detection . . . . . . . . . . . . . . . 13
9.3. Stateless address autoconfiguration . . . . . . . . . . . 13
9.4. Stateful address autoconfiguration . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Patil, et al. Expires April 17, 2007 [Page 2]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
1. Conventions used in this document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
Patil, et al. Expires April 17, 2007 [Page 3]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
2. Introduction
IEEE 802.16d/e is the air interface specification underlying the
WiMAX forums network architecture specification. The 802.16d/e
[802.16e] specification includes the Phy and MAC details. This
document specifies the operation of IPv6 over 802.16d/e in the
context of the WiMAX network architecture. Specifically it is
limited to the operation of IPv6 over the IPv6 convergence sublayer.
The IPv6 convergence sublayer is a part of the 802.16e MAC. The IPv6
link between the mobile station (MS) and the access router (AR) is
considered as a point-to-point link. Assignment of a unique prefix
per MS is recommended in this document. The document provides a
brief overview of the WiMAX network architecture at a high level and
describes the addressing and, transmission and receiving of IPv6
packets, by an MS.
Patil, et al. Expires April 17, 2007 [Page 4]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
3. Terminology
The terminology is based on the definitions used in the network
architecture specified by the WiMAX forum.
BS - The WiMAX Base Station (BS) is a logical entity that embodies a
full instance of the WiMAX MAC and PHY in compliance with the IEEE
802.16 suite of applicable standards. It provides the layer 1/2
connectivity between the network and the MS.
MS - The mobile station is an IPv6 host that connects to the WiMAX
network via an 802.16d/e module.
Transport Connection - 802.16 MAC is connection oriented. Several
types of connections are defined and these include broadcast, unicast
and multicast. Each connection is uniquely identified by a 16 bit
connection identifier (CID). A transport connection is a unicast
connection intended for user traffic. A transport connection is
identified by an uplink and downlink CID. The scope of the transport
connection is between the MS and the BS.
Access Service Network (ASN) - 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.
Access Router (AR) - The Access router is the 1st hop default IPv6
router from the perspective of the MS. The AR is an entity that
exists within the scope of an ASN.
Patil, et al. Expires April 17, 2007 [Page 5]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
4. IEEE 802.16d/e convergence sublayer support for IPv6
IEEE 802.16d/e has specified multiple convergence sublayers (CS) in
the MAC. The convergence sublayers and MAC specifications are
available in [802.16e]. IPv6 can be implemented in two ways:
1. Over the IPv6 convergence sublayer or
2. Over Ethernet (which runs over Ethernet CS).
The figure below shows the options for IPv6 implementation in WiMAX:
-------------- ---------------
| IPv6 | | IPV6 |
-------------- ---------------
| IPv6 CS | | Ethernet |
| .......... | ---------------
| MAC | | Ethernet CS |
-------------- | ........... |
| PHY | | MAC |
-------------- ---------------
IPv6 over IPv6 CS | PHY |
---------------
IPv6 over Ethernet
Figure 1: IPv6 over IPv6 CS and over Ethernet
WiMAX forum has chosen IP CS as the default CS to be supported for IP
connectivity. The scope of this document is limited to IPv6
operation over IPv6 CS only.
Patil, et al. Expires April 17, 2007 [Page 6]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
5. WiMAX network architecture
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
functions such as AAA, Mobile IP Foreign agent, Paging controller,
Location Register etc. 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 2: 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) 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. However all the functions
of an ASN such as the MIP4 FA, AAA, AR exist within the scope of an
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
Patil, et al. Expires April 17, 2007 [Page 7]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
GRE tunnel. The granularity of the GRE tunnel can be on a per flow
basis, per MS basis or on a BS basis. 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 3: 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.
Patil, et al. Expires April 17, 2007 [Page 8]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
6. IPv6 link in WiMAX
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 transport connection over the air interface and
the GRE tunnel between the BS and AR create a tunnel at the layer
below IPv6. 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 a different 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].
6.1. IPv6 link establishment
The mobile station performs initial network entry as specified in
802.16e [Ref80216]. 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.
6.2. Maximum transmission unit
The WiMAX forum [WMF] has specified the 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. Note that the 1522 octet specification is a WiMAX forum
specification and not the size of the SDU that can be transmitted
over 802.16d/e, which is higher. RFC2461 [RFC2461] recommends that
Patil, et al. Expires April 17, 2007 [Page 9]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
IPv6 nodes implement Path MTU discovery. In such cases the default
value can be over-ridden. Additionally if the 802.16d/e MAC layer
can provide an indication of the MTU size to be used, the MS can use
that as the default MTU.
Patil, et al. Expires April 17, 2007 [Page 10]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
7. IPv6 prefix assignment
Each MS can be considered to be on a separate subnet as a result of
the point-to-point cconnection. While the MS can establish multiple
service flows that map to corresponding transport connections over
the air interface, the ISF and any other service flows established
for IPv6 traffic should be treated as a single subnet. A CPE 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 an
ISF. The prefixes are advertised with the on-link (L-bit) flag set
so that MSs may not make any asumption about the existence of on-link
neighbors.
Patil, et al. Expires April 17, 2007 [Page 11]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
8. Router Discovery
8.1. Router Solictation
On completion of the establishment of the IPv6 ISF, the MS may send a
router solicitation message to solicit a Router Advertisement message
from the AR to acquire necessary information as specified in RFC2461
[RFC2461]. An MS that is network attached may also send router
solicitations at any time.
8.2. Router Advertisement
The AR should send a number of router advertisements as soon as the
IPv6 ISF is established to the MS. The AR may send unsolicited
router advertisements periodically as specified in RFC2461 [RFC2461].
However to conserve the battery lifetime of hosts and to conserve
radio resources over the air interface, unsolicited router
advertisement transmission are not recommended.
8.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
periodic router advertisements should be set quite high. The
MaxRtrAdvInterval should be configurable to a value which is greater
than 1800 seconds.
Patil, et al. Expires April 17, 2007 [Page 12]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
9. IPv6 addressing for hosts
The addressing scheme for IPv6 hosts in WiMAX follows the IETFs
recommendation for hosts specified in RFC 4294. The IPv6 node
requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are
applicable for addressing.
9.1. Interface Identifier
The MS has a 48-bit MAC address as specified in 802.16e [802.16e].
This MAC address is used to generate the 64 bit interface identifier
which is used by the MS for address autoconfiguration. The IID is
generated by the MS as specified in RFC2464 [RFC2464]. For addresses
that are based on privacy extensions, the MS may generate random IIDs
as specified in RFC3041 [RFC3041].
9.2. Duplicate address detection
DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462].
9.3. Stateless address autoconfiguration
If the L-bit and A-bit in the prefix information option (PIO) are set
the MS performs stateless address autoconfiguration as per RFC 2461,
2462. The AR in the ASN is the default router that advertises a
unique /64 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 the RFC3315
[RFC3315].
Patil, et al. Expires April 17, 2007 [Page 13]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
10. IANA Considerations
This draft does not require any actions from IANA.
Patil, et al. Expires April 17, 2007 [Page 14]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
11. Security Considerations
This document does not introduce any new vulnerabilities to IPv6
specifications or operation as a result of the 802.16d/e air
interface or the WiMAX network architecture.
Patil, et al. Expires April 17, 2007 [Page 15]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
12. Acknowledgments
TBD.
Patil, et al. Expires April 17, 2007 [Page 16]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
13. References
13.1. Normative References
[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>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2464>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.
[RFC3314] Wasserman, Ed., M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002,
<ftp://ftp.isi.edu/in-notes/rfc3314>.
[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>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004, <ftp://ftp.isi.edu/in-notes/rfc3756 >.
[RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
April 2006, <ftp://ftp.isi.edu/in-notes/rfc4294>.
[RFC4921] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4921, February 2006,
<ftp://ftp.isi.edu/in-notes/rfc4291>.
Patil, et al. Expires April 17, 2007 [Page 17]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
13.2. Informative References
[802.16e] "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.
[WMF] "http://www.wimaxforum.org".
[WiMAXArch]
"WiMAX End-to-End Network Systems Architecture
http://www.wimaxforum.org/technology/documents",
August 2006.
Patil, et al. Expires April 17, 2007 [Page 18]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
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
Syam Madanapalli
LogicaCMG
125 Yemlur P.O.
Off Airport Road
Bangalore, India 560037
Email: smadanapalli@gmail.com
JinHyeock Choi
Samsung AIT
Networking Technology Lab
P.O.Box 111
Suwon, Korea 440-600
Email: jinchoe@samsung.com
Patil, et al. Expires April 17, 2007 [Page 19]
Internet-Draft IPv6 over IPv6 CS in WiMAX October 2006
Full 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.
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.
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 April 17, 2007 [Page 20]
