One document matched: draft-shin-ipv6-ieee802.16-02.txt
Differences from draft-shin-ipv6-ieee802.16-01.txt
Network Working Group M-K. Shin
Internet-Draft J-M. Moon
Expires: August 30, 2006 ETRI
Y-H. Han
Samsung AIT
February 26, 2006
Scenarios and Considerations of IPv6 in IEEE 802.16 Networks
draft-shin-ipv6-ieee802.16-02
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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
As the deployment of IEEE 802.16 networks progresses, IPv6 will be
introduced in IEEE 802.16 networks. The characteristics of IEEE
802.16 networks put special considerations on how IPv6 is used. This
document describes scenarios and considerations on IPv6 adoption in
IEEE 802.16 networks.
Shin, et al. Expires August 30, 2006 [Page 1]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 4
2. Assumptions and Scenarios . . . . . . . . . . . . . . . . . . 5
2.1. Deployment Models . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Hot Zone . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Cellular-like . . . . . . . . . . . . . . . . . . . . 5
2.2. BS Architecture . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Router Separation from BS . . . . . . . . . . . . . . 6
2.2.2. BS and Router in One Box . . . . . . . . . . . . . . . 6
2.3. Addressing Issues . . . . . . . . . . . . . . . . . . . . 7
2.3.1. A Unique Prefix to a MS . . . . . . . . . . . . . . . 7
2.3.2. A Single Prefix to Attached MSs . . . . . . . . . . . 8
2.4. Convergence Sublayer (CS) Types . . . . . . . . . . . . . 8
2.4.1. IP Convergence Sublayer (CS) . . . . . . . . . . . . . 8
2.4.2. Ethernet Convergence Sublayer (CS) . . . . . . . . . . 9
2.5. Summary of Scenarios . . . . . . . . . . . . . . . . . . . 9
3. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Neighbor Discovery for IPv6 . . . . . . . . . . . . . . . 11
3.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 11
3.1.2. Neighbor Unreachability Detection . . . . . . . . . . 12
3.1.3. Duplcate Address Detection . . . . . . . . . . . . . . 12
3.1.4. Router and Prefix Discovery . . . . . . . . . . . . . 12
3.1.5. Redirect Function . . . . . . . . . . . . . . . . . . 13
3.2. Transmission of IPv6 Packets . . . . . . . . . . . . . . . 13
3.3. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 14
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Mobile IPv6 Fast Handovers . . . . . . . . . . . . . . . . 15
5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Multicast Listener Discovery . . . . . . . . . . . . . . . 16
5.2. Interworking with IP Multicast and MBS . . . . . . . . . . 16
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Security Threat Analysis . . . . . . . . . . . . . . . . . 17
7. Multiple Interfaces with Different Properties . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Shin, et al. Expires August 30, 2006 [Page 2]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
1. Introduction
IEEE 802.16d/e [IEEE802.16][IEEE802.16e] supports MSs (Mobile
Stations) moving at vehicular speeds and thereby specifies a system
for combined fixed and mobile broadband wireless access.
As the deployment of IEEE 802.16 networks progresses, the IEEE 802.16
MSs will be connected to IPv6 networks. The characteristics of IEEE
802.16 networks put special considerations on how IPv6 is used. This
document describes scenarios and considerations on IPv6 adoption in
IEEE 802.16 networks.
1.1. Scope of this Document
This document presents issues with discussion on the use of IPv6
protocols when operating over IEEE 802.16 networks. In order to
achieve this, operational, architectural, and addressing scenarios
are first described. The scenarios have an influence on how to adopt
IPv6 to IEEE 802.16 networks. Then, the following considerations
will be intensively discussed based on the scenarios :
Basic IP
In this part, basic IPv6 issues such as Neighbor Discovery, IPv6
packet transmission, addressing, and IPv6 control/management
protocols are discussed.
Mobility
In this part, issues on interworking with the link layer mobility
mechanism and Mobile IPv6 are discussed.
Multicast
In this part, MBS and IPv6 multicast interworking issues are
discussed.
Security
In this part, IPsec and threat model issues are discussed.
Multiple Interface with Different Characteristics
In this part, some requirements for multiple interfaces with
differerent characteristics (e.g., WLAN) are discussed.
Shin, et al. Expires August 30, 2006 [Page 3]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
1.2. Terminology
SS:
Subscriber Station. A general equipment set providing
connectivity between subscriber equipment and a BS.
MS:
Mobile Station. A station in the mobile service intended to be
used while in motion or during halts at unspecified points. A
mobile station (MS) is always a subscriber station (SS) unless
specifically excepted otherwise in this document.
BS:
Base Station. A generalized equipment set providing connectivity,
management and control of MS connections. A unidirectional
mapping between BS and MS medium access control (MAC) peers for
the purpose of transporting a service flow's traffic. Connections
are identified by a connection identifier (CID). All traffic is
carried on a connection.
CID:
Connection IDentifier. A 16-bit value that identifies a
connection to equivalent peers in the MAC of the BS and the MS.
It maps to a service flow identifier (SFID), which also defines
QoS parameters of the service flow associated with that
connection.
MBS:
Multicast and Broadcast Services. Some globally defined service
flows may carry broadcast or multicast information that should be
delivered to a multiple of SSs or MSs.
1.3. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 [RFC2119].
Shin, et al. Expires August 30, 2006 [Page 4]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
2. Assumptions and Scenarios
IEEE 802.16e supports two modes such as 2-way PMP (Point-to-
Multipoint) and Mesh topology wireless networks. In this document,
we focus on 2-way PMP topology wireless networks.
Some of the problems with IPv6 adoption in IEEE 802.16 networks are
described in [I-D.jee-ipv6-802.16-problem-statement]. In this
section, several issues about the operation and the architecture of
IEEE 802.16e networks are addressed. The issues have an influence on
how to adopt IPv6 to IEEE 802.16 networks.
2.1. Deployment Models
From an operational perspective, there are two use cases of IEEE
802.16 standards.
2.1.1. Hot Zone
The success of a Hotspot service with IEEE 802.11 has been prominent.
The new IEEE 802.16 standards basically support such Hotspot services
with large coverage area and high data rate. An area served by one
base station is usually termed 'Hot Zone' because it is considerably
larger than an IEEE 802.11 access point service area called Hotspot.
Large numbers of wireless Internet service providers (Wireless ISPs)
have planned to use IEEE 802.16 for the purpose of high quality
service. A company can use IEEE 802.16 to build up mobile office.
Wireless Internet spreading through a campus or a cafe can be also
implemented with it. The distinct point of this use case is that it
can use unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 &
3.5GHz) band. By using the unlicensed band, the IEEE 802.16 BS might
be used just as a wireless hub which a user purchases to build a
private wireless network in his/her home or laboratory.
Under 'Hot Zone' use case, the IEEE 802.16 BS will be deployed using
an Ethernet (IP) backbone rather than a proprietary backend like
cellular systems. Thus, many IPv6 functionalities will be preserved
when adopting IPv6 to IEEE 802.16 devices.
2.1.2. Cellular-like
IEEE 802.16 BS can offer both fixed communications and mobile
functions unlike IEEE 802.11. In particular, IEEE 802.16e working
group has been standardizing the mobility features. The final
specification of IEEE 802.16e will provide some competition to the
existing cellular systems. This use case will be implemented only
with the licensed spectrum. IEEE 802.16 BS might be deployed with a
proprietary backend managed by an operator. All original IPv6
Shin, et al. Expires August 30, 2006 [Page 5]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
functionalities will not survive and some of them might be
compromised to efficiently serve IPv6 to this 'Cellular-like' use
case.
Under the use case, however, IEEE 802.16 standards are still IP-
centric, providing packet-switched approach, while cellular standards
like GSM have a more circuit-switched approach.
2.2. BS Architecture
We describe two possible deployment architectures of IEEE 802.16
networks. Figure 1 and 2 illustrate the two cases.
2.2.1. Router Separation from BS
In Figure 1, routers are located separated with IEEE 802.16 BSs. In
this case, IEEE 802.16 BSs have only MAC and PHY layers without
router function. A router and several BSs form an IPv6 subnet. BSs
may not have IPv6 stack. But, for management and configuration
purpose, IPv6 stack will be loaded to them. A simple or complex
network equipments may constitute the underlying wired network
between BSs and router. In a subnet, therefore, there are always two
underlying links including IEEE 802.16 wireless link between MS and
BS.
In this case, the methods of IPv6 adoption to IEEE 802.16 may depend
on the underlying network architecture between BSs and router.
Note that this draft does not address this scenario at this phase.
Its considerations will be discussed later.
2.2.2. BS and Router in One Box
Figure 2 represents an alternative IEEE 802.16 network deployment
where a BS is integrated with a router, composing one box in view of
implementation. A subnet consists of only single router and single
BS.
In this case, many IPv6 functionalities can be implemented without
much consideration about the underlying network implementation. Only
IEEE 802.16 link will be taken into consideration for IPv6 adoption.
Shin, et al. Expires August 30, 2006 [Page 6]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
/-------------------------------------\
| Backbend Network |
\-------------------------------------/
| |
/-----------\ /-----------\
| Router1 | | Router2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 1: IEEE 802.16e deployment architecture with BS and Router in
seperated boxes
/------------------\
| Backbend Network |
\------------------/
/ \
/ \
/ \
--------- ---------
| Router1 | | Router2 |
| BS1 | | BS2 |
--------- ---------
Figure 2: IEEE 802.16e deployment architecture with BS and Router in
one box
2.3. Addressing Issues
There are two possible addressing schemes as follows.
2.3.1. A Unique Prefix to a MS
RFC 3314 recommends that a given prefix should be assigned to only
one primary PDP context so that 3GPP terminals are allowed to
generate multiple IPv6 address using the prefix without the concerns
of address confliction. This recommendation can be also applied to
IEEE 802.16 network system if it is reasonable to the given usage
scenario (e.g., 'Cellular-like' usage scenario). In such case, many
IPv6 functionalities can be implemented without difficulty.
Shin, et al. Expires August 30, 2006 [Page 7]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
2.3.2. A Single Prefix to Attached MSs
Different usage scenario such as 'Hot zone' would not allow RFC 3314
recommendation because of the compatibility with the existing IPv6
devices. In this case, there will be more issues for adopting IPv6
to IEEE 802.16.
2.4. Convergence Sublayer (CS) Types
IEEE 802.16 Convergence Sublayer (CS) provides the tunneling of
IP(v6) packets over IEEE 802.16 air-link. The tunnels are identified
by the Connection Identifier (CID). Generally, CS performs the
following functions in terms of IP packet transmission: 1) Receipt of
protocol data units (PDUs) from the higher layer, 2) Performing
classification and CID mapping of the PDUs, 3) Delivering the PDUs to
the appropriate MAC SAP, 4) Receipt of PDUs from the peer MAC SAP.
[IEEE802.16] defines several CSs for carrying IP packets, but does
not provide a detailed description of how to carry them. The several
CSs are classified into two types of CS: IP CS and Ethernet CS. The
followings include the description of the two types.
2.4.1. IP Convergence Sublayer (CS)
Using IP CS, an IEEE 802.16 MAC frame is followed by IPv6 header.
That is, IP CS only carries IP packets as the payloads of IEEE 802.16
MAC frame. In terms of IP layer, therefore, the link-layer addresses
of IPv6 neighbors are not utilized at all. Accordingly, it is not
easy (or even needless) to support address resolution, router
discovery, and address auto-configuration, etc. With IP CS, the
classification and CID mapping will be performed based on destination
IP address, source IP address, destination port, and source port.
Sometimes, the QoS-related fields of IPv6 header such as 'class' and
'flow label' may be additionally used for QoS and prioritization
purposes.
IP CS is adequate to support the point-to-point type of communication
between a SS and a BS/Router when the next-hop of the outbound
packets sent by a SS is pre-defined and fixed to a network node, such
as BS or access router. At this case, it is not well-grounded to
support all IPv6-related function. Rather, some functions will be
implemented in a proprietary manner.
IP CS does not require any header to carry a link-layer address, it
can save some bandwidth of IEEE 802.16 air-link.
Shin, et al. Expires August 30, 2006 [Page 8]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
2.4.2. Ethernet Convergence Sublayer (CS)
[IEEE802.16] introduces 'IPv6(v4)-over-ethernet CS' which permits
classifiers that examine fields in Ethernet headers as well as fields
of IPv6 (and encapsulated TCP/UDP headers) that are encapsulated in
IEEE 802.3-style frames. An IEEE 802.16 MAC frame is followed by
IEEE 802.3 Ethernet header, which then followed by IP header. This
type of CS can well support IEEE 802-style broadcast network service.
The emulation of the broadcast network with Ethernet CS can allow IP
layer to see an IEEE 802.16 link as a LAN and support IPv6 neighbor
discovery (ND) protocol without difficulty. Ethernet CS can also
support point-to-point service via PPPoE optionally.
Since additional IEEE 802.3 Ethernet header is always located between
IEEE 802.16 MAC frame and IPv6 header, some overload over IEEE 802.16
air-link is inevitable. But, it can be alleviated by using IEEE
802.16 Payload Header Suppression.
For the detailed description of Ethernet CS, see [I-D-mandin-ip-over-
80216-ethcs].
2.5. Summary of Scenarios
As a result of the combination of the above four issues, we got 16
scenarios as follows.
Shin, et al. Expires August 30, 2006 [Page 9]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
+--+---------------+---------------------------+----------------------+-----+
| #| Depolyment | BS Architecture | Addressing | CS |
+--+---------------+---------------------------+----------------------+-----+
| 1| Hot zone | Router separation from BS | Unique Prefix to a MS| IP |
+--+---------------+---------------------------+----------------------+-----+
| 2| Hot zone | Router separation from BS | Single Prefix to MSs | IP |
+--+---------------+---------------------------+----------------------+-----+
| 3| Hot zone | BS and router in one box | Unique Prefix to a MS| IP |
+--+---------------+---------------------------+----------------------+-----+
| 4| Hot zone | BS and router in one box | Single Prefix to MSs | IP |
+--+---------------+---------------------------+----------------------+-----+
| 5| Cellular-like | Router separation from BS | Unique Prefix to a MS| IP |
+--+---------------+---------------------------+----------------------+-----+
| 6| Cellular-like | Router separation from BS | Single Prefix to MSs | IP |
+--+---------------+---------------------------+----------------------+-----+
| 7| Cellular-like | BS and router in one box | Unique Prefix to a MS| IP |
+--+---------------+---------------------------+----------------------+-----+
| 8| Cellular-like | BS and router in one box | Single Prefix to MSs | IP |
+--+---------------+---------------------------+----------------------+-----+
| 9| Hot zone | Router separation from BS | Unique Prefix to a MS| Eth |
+--+---------------+---------------------------+----------------------+-----+
|10| Hot zone | Router separation from BS | Single Prefix to MSs | Eth |
+--+---------------+---------------------------+----------------------+-----+
|11| Hot zone | BS and router in one box | Unique Prefix to a MS| Eth |
+--+---------------+---------------------------+----------------------+-----+
|12| Hot zone | BS and router in one box | Single Prefix to MSs | Erh |
+--+---------------+---------------------------+----------------------+-----+
|13| Cellular-like | Router separation from BS | Unique Prefix to a MS| Eth |
+--+---------------+---------------------------+----------------------+-----+
|14| Cellular-like | Router separation from BS | Single Prefix to MSs | Eth |
+--+---------------+---------------------------+----------------------+-----+
|15| Cellular-like | BS and router in one box | Unique Prefix to a MS| Eth |
+--+---------------+---------------------------+----------------------+-----+
|16| Cellular-like | BS and router in one box | Single Prefix to MSs | Eth |
+--+---------------+---------------------------+----------------------+-----+
Figure 3: Scenarios considered for IPv6 adoption to IEEE 802.16
Note that at this phase, we don't address considerations according to
all the senarios. These will be intensively discussed later.
Shin, et al. Expires August 30, 2006 [Page 10]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
3. Basic IP
3.1. Neighbor Discovery for IPv6
In IEEE 802.16 networks, some Neighbor Discovery [RFC2461] messages
can be unnecessary in certain cases, since MS and BS/router links
resemble a point-to-point link; hence, the MS's only neighbor is the
the BS/router which is already known through the link configuration
(e.g., network entry) mechanisms. Also, Neighbor Discovery packets
with a multicast destination address (e.g., all-node-multicast, or
all-router-multicast addresses) are also transmitted as normal IEEE
802.16 MAC frames, as the same as regular unicast packets. Normal
802.16 MAC headers do not include MAC addresses. Instead, in order
to identify connections to equivalent peers in the MAC of the BS/
router and the MS, CID is used. In certain cases, multicast CID may
be provided for in the downlink. It can be useful to tranmit
efficiently link-local multicast destination packets (e.g, Router
Advertisements) from BS/router to MSs. The packet transmission
issues are discussed in section 3.2.
In some scenarios, the router may be separated from the BS. Two
different link connections must be bridged for one network connection
between and the MS and the router (e.g., 802.16 link + Ethernet). In
case of the scenarios, the operations and issues may be different
(i.e., CID mapping and Neighbor Discovery packets transmission).
These issues will be discussed later.
Note that considerations of Neighbor Discovery in IEEE 802.16
networks are being discussed in an other document [I-D.lee-ndp-
ieee802.16].
Neighbor Solicitation and Neighbor Advertisement messages can be
classified into three functions; Address Resolution, Neighbor
Unreachabilit Detection and Duplcate Address Detection. Also, Router
Solicitation and Router Advertisement messages are used for Router
and Prefix Discovery.
3.1.1. Address Resolution
Neighbor Solicitation and Neighbor Advertisement messages for address
resolution delivered between the MS and BS/router are not needed,
since MS and BS/router links resemble a point-to-point link; hence,
the MS's only neighbor is the BS/router which is already known
through the link configuration (e.g., network entry) mechanisms.
Actually, Neighbor Cache entries may be unnecessary. Since CID is
used for link-layer transmission, CID connection state is maintained,
instead of Neighbor Cache entries. The MS uses CID which is provided
to each connection by the BS/router. It must ensure the uniqueness
Shin, et al. Expires August 30, 2006 [Page 11]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
of such connections on the link.
3.1.2. Neighbor Unreachability Detection
In general, Neighbor Unreachability Detection is used for all paths
between hosts and neighboring nodes. However, this function is used
only between MS and BS/router, since the MS's only neighbor is the
BS/router.
The Neighbor Unreachability Detection portion of IPv6 Neighbor
Discovery protocol is not needed, since MS and BS/router don't
maintain Neighbor Cache entries. But the MS and BS/router must know
their neighbor reachability at the IP layer in certain cases. A BS/
router is considered reachable if the MS has recently received a
confirmation that packets sent recently to the neighbor were received
by its IP layer. Reachability confirmation can be gathered in two
ways: hints from upper layer protocols that indicate a connection is
making "forward progress", or from link layer mechanisms that
indicate a "link up" in IEEE 802.16 networks.
3.1.3. Duplcate Address Detection
Usually, a BS/router may assign a prefix that is unique to a MS.
Therefore, this avoids the necessity to perform Duplicate Address
Detection. The allocation of a prefix to a MS will alow the MSs to
implement the IPv6 stateless address auto-configuration [RFC2462] and
privacy extension [RFC3041] without the need for further Duplicate
Address Detection.
However, if BS/router assigns a single prefix to all of its attached
MSs, Duplicate Address Detection must send Neighbor Solicitation
messages with an unspecified source address targeting its own
tentative address. In order to efficiently perform a multicast
Neighbor Advertisement for a response, a BS/router can perform proxy
Neighbor Advertisements for one or more other MSs. In certain cases,
multicast CID may be used to send the proxy Neighbor Advertisements
to the MSs in the downlink.
It might be dependent on the scenarios of IPv6 addressing scenarios
described in section 2.3. This issus is also discussed in section
3.3.
3.1.4. Router and Prefix Discovery
Router Discovery is already performed by link layer configuration
mechanisms. As for Prefix Discovery, a BS/router trasmits Router
Advertisements that contain Prefix Information to the advertising
interface whose corresponding AdvSendAdvertisements flag is TRUE.
Shin, et al. Expires August 30, 2006 [Page 12]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
The AdvSendAdvertisements flag must be set when CID is set for a
connection. A BS/router must not send Router Advertisements out to
any interface that is not an advertising interface. In this case, a
multicast CID can be used to to transmit the Router Advertisements to
the MSs in the downlink.
To obtain Router Advertisements quickly, a MS can send Router
Solicitations to its BS/router. In this case, the MS's CID is used
to identify the MS.
3.1.5. Redirect Function
The Redirect message is not necessary in IEEE 802.16 networks, since
the MS's only router is the BS/router and the MS cannot send a packet
to other MS without the BS/router.
3.2. Transmission of IPv6 Packets
IEEE 802.16 MAC header format is described in [IEEE802.16].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IEEE 802.16 MAC header format
It is importmant to see that there is no MAC address in IEEE 802.16
the MAC header format. Similar to general point-to-point links, the
MAC address is not used for link-layer transmission. Hence, mapping
unicast or multicast addresses to IEEE 802.16 MAC addresses is
unnecessary. Also, link-local addressess may be not needed for
transmission of link-local destination packets. Instead, CID is used
to identify connections to equivalent peers in the MAC of the BS and
the MS in IEEE 802.16 networks.
In some scenarios, the router may be separated from the BS. Two
different link connections must be bridged for one network connection
between and the MS and the router (e.g., 802.16 link + Ethernet). In
these cases, standard Path MTU Disovery may not work well. These
issues is being discussed in [I-D.shin-16ng-ipv6-transmission].
Shin, et al. Expires August 30, 2006 [Page 13]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
In certain cases, multicast CID can be provided for in the downlink.
It can be useful to transmit efficiently link-local multicast
destination packets in the downlink.
3.3. IPv6 Addressing
There are two possiblities to allocate an IPv6 prefix in 802.16
networks. The simple method is to assign a unique prefix to a MS.
This avoids the necessity to perform Duplicate Address Detection.
The second method is to assign a single prefix to all of its attached
MSs. In this case, Duplicate Address Detection must be supported.
It might be dependent on the scenarios of the IPv6 addressing model.
This issus should be intensively researched later, since it will
affect the protocol implementation of Duplicate Address Detection.
Shin, et al. Expires August 30, 2006 [Page 14]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
4. Mobility
As for mobility management, the movement between BSs is handled by
Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in
certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the
link mobility information must be available for facilitating layer 3
handoff procedure.
4.1. Mobile IPv6
Mobile IPv6 defines that movement detection uses Neighbor
Unreachability Detection to detect when the default router is no
longer bi-directionally reachable, in which case the mobile node must
discover a new default router. Periodic Router Advertisements for
rechability and movement detection may be unnecessary becasue IEEE
802.16 MAC provides the reachabilty by the Ranging procedure and the
movement detection by the Handoff procedure.
4.2. Mobile IPv6 Fast Handovers
In addition, IEEE 802.16 defines L2 triggers whether refresh of a IP
address is required during the handoff. Though a handoff has
occurred, an additional Router Discovery procedure is not required in
case of intra-subnet handoff. Also, faster handoff may be occurred
by the L2 trigger in case of inter-subnet handoff.
Also, IEEE 802.16g which is under-developed defines L2 triggers for
link status auch as link-up, link-down, handoff-start. These L2
triggers may make the mobile IPv6 procedure more efficient and
faster. In addition, Mobile IPv6 Fast Handover assumes the support
from link-layer technology, but the particular link-layer information
being available, as well as the timing of its availability (before,
during or after a handover has occurred), differs according to the
particular link-layer technology in use.
This issue is also being dicussed in [I-D.jang-mipshop-fh80216e].
Shin, et al. Expires August 30, 2006 [Page 15]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
5. Multicast
In order to support multicast services in IEEE 802.16, Multicast
Listener Discovery [RFC2710] must be supported between the MS and BS/
router. Also, interworking with IP multicast protocols and MBS
should be considered.
5.1. Multicast Listener Discovery
Within IEEE 802.16 networks, a MS connects to its BS/router via
point-to-point links. Multicast Listener Discovery sends link-local
multicast destination queries and reports. The packets are
transmitted as normal IEEE 802.16 MAC frames, as the same as regular
unicast packets. Especially, multicast CIDs can be used to transmit
efficiently query packets on the downlink.
There are exactly two IP devices connected to the point-to-point
link, and no attempt is made (at the link-layer) to suppress the
forwarding of multicast traffic. Consequently, sending Multicast
Listener Discovery reports for link-local addresses in IEEE 802.16
network environment may not always be necessary. Multicast Listener
Discovery is needed for multicast group knowledge that is not link-
local.
5.2. Interworking with IP Multicast and MBS
MBS defines Multicast and Broadcast Services, but actually, MBS seems
to be a broadcast service, not multicasting. MBS adheres to
broadcast services, while taditional IP multicast schemes define
multicast routing using a shared tree or source-specific tree to
deliver packets efficiently.
In IEEE 802.16 networks, two types of access to multicast and
broadcast services (MBS) may be supported: single-BS access and
multi-BS access. Therefore, these two types of services may be
roughly mapped into Source-Specific Multicast.
It should be intensively researched later, since MBS will be one of
the killer services in IEEE 802.16 networks.
Shin, et al. Expires August 30, 2006 [Page 16]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
6. Security
6.1. IPsec
IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may
be used within the global end-to-end architecture. But, we don't
have PKIs across organizations and IPsec isn't integrated with IEEE
802.16 network mobility management.
6.2. Security Threat Analysis
IEEE 802.16 network threats may be different with IPv6 and IPv6
transition threat models [I-D.ietf-v6ops-security-overview]. It will
be discussed later.
Shin, et al. Expires August 30, 2006 [Page 17]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
7. Multiple Interfaces with Different Properties
If a MS has additional interfaces on which IP is used (such as
Ethernet, WLAN), then there may be additional problems for the
device.
Some of these problems are :
Protocol inconsitancy problems with the same fuctionalities:
If an MS has additional interfaces on which IP is used, we need to
figure out any protocol inconsitancy if there are protocol issues
(modification) in IEEE 802.16 networks. Two or more different
versions of protocols (e.g., NDP) may be required within the
TCP/IP stack on the same MS.
Roaming/movement problems between heterogenous networks:
will be discussed later.
MS multi-homing problems:
will be discussed later.
Shin, et al. Expires August 30, 2006 [Page 18]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
8. Security Considerations
As for security, it is briefly discussed in section 6.
Shin, et al. Expires August 30, 2006 [Page 19]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004.
9.2. Informative References
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316,
April 2003.
[I-D.jang-mipshop-fh80216e]
Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", draft-jang-mipshop-fh80216e-01 (work in
progress), December 2005.
[I-D.ietf-v6ops-security-overview]
Davies, E., "IPv6 Transition/Co-existence Security
Considerations", draft-ietf-v6ops-security-overview-03
Shin, et al. Expires August 30, 2006 [Page 20]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
(work in progress), October 2005.
[I-D.mandin-ip-over-80216-ethcs]
Mandin, J., "Transport of IP over 802.16",
draft-mandin-ip-over-80216-ethcs-00 (work in progress),
October 2005.
[I-D.lee-ndp-ieee802.16]
Lee, J., "Considerations of NDP over IEEE 802.16
Networks", draft-lee-ndp-ieee802.16-00 (work in progress),
October 2005.
[IEEE802.16]
"IEEE 802.16-2004, IEEE standard for Local and
metropolitan area networks, Part 16:Air Interface for
fixed broadband wireless access systems", October 2004.
[IEEE802.16e]
"IEEE 802.16e/D10 Draft, IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed and Mobile Broadband Wireless Access Systems
Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", August 2005.
Shin, et al. Expires August 30, 2006 [Page 21]
Internet-Draft IPv6 in IEEE 802.16 Networks February 2006
Authors' Addresses
Myung-Ki Shin
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 4847
Email: myungki.shin@gmail.com
Jung-Mo Moon
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 6748
Email: jmmoon@etri.re.kr
Youn-Hee Han
Samsung AIT
P.O. Box 111
Suwon 440-600
Korea
Email: yh21.han@gmail.com
Shin, et al. Expires August 30, 2006 [Page 22]
Internet-Draft IPv6 in IEEE 802.16 Networks February 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.
Shin, et al. Expires August 30, 2006 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:43 |