Network Working Group H. Jeon
Internet-Draft S. Jeong
Intended status: Standards Track ETRI
Expires: March 5, 2007 M. Riegel
Siemens
Sep 2006
Transmission of IPv6 packets over Ethernet CS over IEEE 802.16 network
draft-jeon-ipv6-over-ieee802.16-ethcs-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes transmission of IPv6 packets over Ethernet CS
over IEEE 802.16 network. In this document, two possible network
deployment scenarios are discussed and behaviors for corresponding
scenario are suggested in order to support IPv6 transmission over
Ethernet CS over IEEE 802.16 network.
Jeon, et al. Expires March 5, 2007 [Page 1]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IEEE 802.16 Network Model on IPv6 over Ethernet CS . . . . . . 4
6. Transmission on IPv6 over Ethernet CS . . . . . . . . . . . . 6
6.1. On-Link Issue . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 8
7. IPv6 NDP Operations on IPv6 over Ethernet CS . . . . . . . . . 8
7.1. Identification Cache Table . . . . . . . . . . . . . . . . 8
7.2. Router Discovery, Prefix Discovery and Parameter
Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Address Resolution . . . . . . . . . . . . . . . . . . . . 9
7.4. Duplicate Address Detection . . . . . . . . . . . . . . . 9
7.5. IPv6 NDP Multicast Transmission . . . . . . . . . . . . . 10
7.5.1. Solicited-node Multicast Transmission using
Replicated Unicast . . . . . . . . . . . . . . . . . . 10
7.5.2. All-node Multicast Transmission using Common CID . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Jeon, et al. Expires March 5, 2007 [Page 2]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
1. Introduction
TBD
2. Requirements
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].
3. Terminology
Description of following some terms is taken directly from [IEEE
802.16] and [IEEE 802.16e].
Base Station (BS): A generalized equipment set providing
connectivity, management, and control of the subscriber station.
Subscriber Station (SS): A generalized equipment set providing
connectivity between subscriber equipment and a base station.
Service-specific Convergence Sublayer (CS): Sublayer in IEEE 802.16
MAC layer which classifier external network data and associates
them to the proper MAC service flow identifier and connection
identifier.
Connection Identifier (CID): A 16 bit value that identifies a
connection to equivalent peers in the MAC of the base station and
subscriber station.
Source SS: SS which initiates IPv6 NDP message.
Target SS: SS which is identified with target field in IPv6 NDP
message.
Source BS: BS where Source SS is located.
Target BS: BS where Target SS is located.
Dynamic Service Addition (DSA): The set of messages and protocols
that allow the base station and subscriber station to add the
characteristics of a service flow.
Jeon, et al. Expires March 5, 2007 [Page 3]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
Multicast and Broadcast Services: Globally defined service flow that
carries broadcast or multicast information towards a plurality of
SS.
Multicast and Broadcast Services Connection ID (MBS-CID): Traffic
CID for MBS.
Common Connection Identifier (CCID): CID shared by all SSs and BS
for the purpose of transmitting IPv6 Neighbor Discovery messages
with all-node multicast address.
4. Assumption
This document supposes following assumption.
o All SSs attached to same AR share one or multiple prefixes so that
multiple BSs and SSs form an IPv6 subnet. All MSs attached to
different BSs under the same AR, can be on same IPv6 link
o IEEE 802.16 BS supports local realy function. In general, MAC
Bridge does not relay incoming packet to its incoming port again.
Hence, IPv6 Neighbor Discovery messages cannot be transmitted to
other SSs served by same BS without local relay function. This
document supposes IEEE 802.16 BS relays the IPv6 Neighbor
Discovery messages before delivering them to MAC Bridge.
5. IEEE 802.16 Network Model on IPv6 over Ethernet CS
IEEE 802.16 access technology is different from existing wireless
access technologies such as IEEE 802.11 or 3G, because IEEE 802.16
only defines the encapsulation of an IP packet into an IEEE 802.16
MAC payload without a complete description of IPv6 operation. Also,
the existence of various Convergence Sublayers (CS) introduces
various IEEE 802.16 based network deployment architecture. This
document discusses possible deployment scenarios in case of VLAN CS
as well as Ethernet CS.
Figure 1 shows IEEE 802.16 network deployment scenario with direct
host-to-host communication. In this scenario, a BS is separated from
an access router, there exist multiple access routers in a link, and
a subnet consists of multiple BSs and SSs. In addition to that,
there may exist a network behind SS/Gateway, i.e. Wireless DSL
equipment. The network behind SS/Gateway can support various access
network technologies such as 802.11, Ethernet, and so on.
Jeon, et al. Expires March 5, 2007 [Page 4]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
Ethernet links BSs to ARs and they are connected via Ethrenet
Swithch. In this scenario, SS and BS utilize VLAN CS as well
Ethernet CS and VLANs comprise SSs attached to several BSs. When the
VLANs are deployed, direct host-to-host communication is available.
Thus, IP features such as multi-homing and native multicasting can be
easily supported.
+-----+ +---+ +----+ +-----+ ISP 1
| SS1 |-+ | | +---|AR1 |---| ER1 |===>Net
+-----+ | | S| | +----+ +-----+
+-----+ | +-----+ |E w| |
| SS2 |-+--| BS1 |--|t i| |
+-----+ +-----+ |h t|--+
| c| | +----+ +-----+ ISP 2
+-----+ +-----+ +-----+ | h| +---|AR2 |---| ER2 |===>Net
|Hosts|--|SS/GW|----| BS2 |--| | +----+ +-----+
+-----+ +-----+ +-----+ +---+
This network
may exist behind
SS/GW
Figure 1. IEEE 802.16 Network Model on IPv6 over Ethernet CS
(with direct host-to-host communication)
Figure 2 shows the case attaching SSs over Ethernet CS without direct
host-to-host communication. In general public access case, direct
communication between hosts is restricted because of security issue,
such as attacks by malicious users.
In this case, connections from SS are extended from the BS to the AR.
The extension can be achieved by using GRE tunnel with CID
granularity.
Jeon, et al. Expires March 5, 2007 [Page 5]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
+-----+
| SS1 |-----+
+-----+ |
|
|
+-----+ | +-----+ +---+ +----+ ISP
| SS2 |-----+-----| BS1 |----------|AR |---| ER |===>Net
+-----+ | +-----+ +---+ +----+
| ____________
| ()__________()
+-----+ +-----+ | GRE Tunnel
|Hosts|--|SS/GW |----+
+-----+ +-----+
Figure 2. IEEE 802.16 Network Model on IPv6 over Ethernet CS
(without direct host-to-host communication)
6. Transmission on IPv6 over Ethernet CS
6.1. On-Link Issue
The assignment of a common prefix to all SSs under a specific AR
means locating them "on-link" in terms of IP packet transfer.
According to [I-D.ietf-ipv6-2461bis], IP node performs a longest
prefix match against the prefix list in order to decide whether the
destination of the IP packet is on-link or not. Therefore, SSs
sharing a prefix can be said to on-link IP nodes.
Section 5 says that direct communication among SSs is depending on
the type of IEEE 802.16 network model scenario. Above the second
scenario does not support direct communication between SSs and it
results in the problem of locating SSs on-link in terms of IP packet
transfer.
By the way, VLAN in the first scenario allows each SSs to communicate
each other directly. Therefore, all IPv6 NDP messages can be
exchanged between SSs and there is no On-Link issue.
This document considers behaviors in the first scenario. First
scenario will be handled in next version of document.
6.2. Frame Format
[IEEE802.16e] defines several CSs for carrying upper layer data.
Currently, IP CS and Ethernet CS is defined to transport packet-based
protocols. IPv6 packets can be transmitted in IEEE 802.16 Generic
Jeon, et al. Expires March 5, 2007 [Page 6]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
MAC frames with Ethernet CS as shown in Figure 2. When Ethernet CS
is used, Ethernet header MUST be included in the payload of IEEE
802.16 MAC frame.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| Type |S|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet |
+- -+
/ header /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IEEE 802.16 Frame Format for IPv6 over Ethernet CS
o H: Header Type. Shall be set to zero for Generic MAC header
o E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
is encrypted.
o Type: This field indicates the subheaders and special payload
types present in the message payload
o S: Extended Subheader Field (ESF). If ESF = 1, the extended
subheader is present. If ESF = 1, no extended subheader is
included
o C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
o R: Reserved. Shall be set to zero.
o EKS: Encryption Key Sequence
o LEN: Length
o CID: Connection Identifier
Jeon, et al. Expires March 5, 2007 [Page 7]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
o HCS: Header Check Sequence
o CRC: An optional 4 octets field (refer to Section 6.3.3.5 in [IEEE
802.16]. CRC appended to the PDU after encryption.
6.3. Maximum Transmission Unit
Since IEEE 802.16 provides link layer fragmentation and reassembly
function, the MTU for IEEE 802.16 link is not specified in
[IEEE802.16]. However, in the Ethernet CS deployment model, BSs and
ARs may be connected via Ethernet. Therefore, a value of 1500 octets
is recommended for the MTU of the IPv6 packets in order to keep
compatibility with Ethernet.
Note that the value does not consider where stacked VLANs are
tranferred over the air and GRE tunnel is established between BS and
AR. Deployment scenario considering above situation should consider
additional sizes by VLAN header and GRE header.
7. IPv6 NDP Operations on IPv6 over Ethernet CS
7.1. Identification Cache Table
BS maintains Identification Cache Table (ICT), which includes
information on SSs covered by the BS. The ICT contains MAC address,
IPv6 address of SS, and DAD flag. If DAD flag is set, the ICT should
include tentative target address in DAD Neighbor Solicitation (NS).
The ICT should be preferable co-located with the bridging table. The
ICT is constructed by following operations.
o BS can learn L2 address of SS during the initial ranging procedure
of IEEE 802.16 specified in Section 6.3.1.1 in [IEEE 802.16].
(Note that this approach may be not sufficient if there are
multiple hosts connected behind a MAC bridge on SS. We need a
reliable mechanism also to learn MAC addreesses behind the SS.)
o BS can learn L3 address of SS with Target field in DAD NS which is
not responded with DAD NA. (NOTE: it seems unreliable. We have
to look for another method, not using DAD NS/NA)
7.2. Router Discovery, Prefix Discovery and Parameter Discovery
Router Discovery, Prefix Discovery and Parameter Discovery procedures
are achieved by receiving Router Advertisement (RA) message. The RA
is advertised by using all-node multicast transmission. If IEEE
802.16 does not support IPv6 multicast transmission, the multicast
transmission should be emulated with the way described in Section
Jeon, et al. Expires March 5, 2007 [Page 8]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
7.5.2.
Considering the power consumption on SS, we recommend that AR should
just unicast the RA in response with RS without using all-node
multicast transmission. It can prevent SS from frequently being
woken in idle mode.
There can be drawbacks caused by the non-periodic RA messages. We
will consider the drawbacks in next version of doucment.
7.3. Address Resolution
When Source SS sends NS for Address Resolution, MAC bridge function
on Source BS relays the NS toward backbone Ethernet link. Each BSs
attached the backbone receive the NS and identify Target BS for the
NS by referring its own ICT. Other BSs, not Target BS, ignore the
NS.
If network approves the proxy function for NDP, Target BS refers the
ICT and responds to the NS instead of Target SS.
Otherwise, Target BS relays the NS message toward its own air using
replicated unicast mechanism specified in Section 7.5.1. Target SS
responds to the NS.
7.4. Duplicate Address Detection
When Source BS receive DAD NS from Source SS, the Source BS set DAD
flag in ICT to non-zero and store tentative address in Target Address
field in DAD NS so that it can identify who sends the DAD NS. MAC
bridge on Source BS relays the DAD NS toward backbone Ethernet link.
Each BSs attached the backbone receive the DAD NS and identify Target
BS for the DAD NS by referring its own ICT. Other BSs, not Target
BS, ignore the DAD NS.
If network approves the proxy function for NDP, Target BS refers the
ICT to see whether the tentative target address in the DAD NS exists
in its own ICT table. If it exists, Target BS responds with DAD NA.
Otherwise, discard the DAD NS message silently.
If the proxy function is not available, Target BS relays the DAD NS
message toward its own air using replicated unicast mechanism
specified in Section 7.5.1. If the tentative target address is in
use, Target SS responds with DAD NA. Otherwise, the DAD NS message
is ignored.
When each BSs receive the DAD NA message, the BSs refer to DAD flag
and tentative target address in ICT table to see whether Source SS is
Jeon, et al. Expires March 5, 2007 [Page 9]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
located in its serving area. If existing, the BS sends the DAD NA
using Common CID specified in Section 7.5.2.
7.5. IPv6 NDP Multicast Transmission
IPv6 Neighbor Discovery messages except Redirect are destined to
link-local scoped multicast address such as all-router multicast
address, all-node multicast address, and solicited-node multicast
address.
Since IEEE 802.16 specification does not provide dedicated CIDs for
IPv6 multicast packet transmission, any available traffic CID value
needs to be allocated for multicasting IPv6 packet.
Following subsections describe how to transmit the packets with link-
local scoped multicast address into IEEE 802.16 network according to
different type of link-local scoped multicast address.
7.5.1. Solicited-node Multicast Transmission using Replicated Unicast
In the wireless environment, it is important to avoid all-node
multicast transmission in order to prevent unrelated SSs from
frequently being woken from idle mode.
Solicited-node multicast address is not for all nodes and can be seen
a pseudo-unicast. Hence, we can leave the above situation out of
consideration when using solicited-node multicasting.
Replicated Unicast is to deliver IPv6 Neighbor Discovery messages by
repeated unicast transmissions towards SSs involved in the multicast
address of the IPv6 Neighbor Discovery message.
IPv6 Neighbor Discovery messages with solicited-node multicast
address should be transmitted by replicated unicasts via CIDs of
corresponding SSs. Thus, it is required to identify CIDs for
solicited-node multicast addresses.
Section 6.3.1.1 in [IEEE 802.16] states that a 48-bit universal MAC
address of SS is used during the initial ranging process to identify
connections to SS. Solicited-node multicast address of SS can be
derived by the MAC address. As a result, BS can be aware of the
solicited-node multicast addresses with the known MAC address of each
SS and match the derived addresses with each CIDs. (Note that we
need further consideration to obtaining MAC addresses of multiple
hosts behind a SS.)
Jeon, et al. Expires March 5, 2007 [Page 10]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
7.5.2. All-node Multicast Transmission using Common CID
This section defines Common CID (CCID) for transmitting all-node
multicast data. There is one unique CCID in BS and it is shared by
all SSs served by the BS. All SSs can receive data transmitted via
the CCID.
Current IEEE 802.16 does not specify CID which can be shared by all
SSs and used for IP data. Following describes how to make CCID with
existing MBS-CID.
[IEEE 802.16e] proposes Multicast and Broadcast Service (MBS), which
presents media service to SSs using multicast or broadcast. Under
MBS architecture, each SS selects MBS contents and then configures a
corresponding CID by the DSA procedure. Such a CID for MBS is
referred to as MBS-CID. MBS-CID is one of transport CIDs and is
shared by all SSs requesting same media content.
CCID can be seen as a special type of MBS-CID. CCID is allocated to
BS and all SSs served by the BS utilizing a general DSA procedure in
MBS for transmitting link-local multicast data. For the assigning
the CCID, we assume that service flow for all-node multicast is
globally defined and the service flow is known to BS and all SSs.
Once initialization between BS and SS is completed, they perform DSA
procedure for creating the all-node multicast service flow. The
detailed process creating new service flow and updating CS for
mapping of the service flow to CCID is outside scope of this
document.
BS transmits IPv6 Neighbor Discovery messages with all-node multicast
address towards all SSs via the CCID.
8. Security Considerations
IEEE 802.16e architecture supports a number of mandatory
authorization mechanisms such as EAP-TTLS, EAP-SIM and EAP-AKA.
[RFC 3971] specifies security mechanisms for NDP and defines securing
NDP messages.
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.
Jeon, et al. Expires March 5, 2007 [Page 11]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
9.2. Informative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-07 (work in progress), May 2006.
[I-D.ietf-v6ops-802-16-deployment-scenarios]
Shin, M. and Y. Han, "ISP IPv6 Deployment Scenarios in
Wireless Broadband Access Networks",
draft-ietf-v6ops-802-16-deployment-scenarios-00 (work in
progress), May 2006.
[I-D.jee-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statements and Goals",
draft-jee-16ng-ps-goals-00 (work in progress),
February 2006.
[IEEE802.16]
IEEE Std 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 P802.16e/D10, "Draft 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", Auguest 2005.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Jeon, et al. Expires March 5, 2007 [Page 12]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006
Authors' Addresses
Hongseok Jeon
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-3892
Email: jeonhs@etri.re.kr
Sangjin Jeong
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-1877
Email: sjjeong@gmail.com
Max Riegel
Siemens
St-Martin-Str 76
Munich, 81541
Germany
Phone: +49-89-636-75194
Email: maximilian.riegel@siemens.com
Jeon, et al. Expires March 5, 2007 [Page 13]
Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 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).
Jeon, et al. Expires March 5, 2007 [Page 14]