Internet DRAFT - draft-shin-16ng-ipv6-transmission
draft-shin-16ng-ipv6-transmission
Network Working Group M-K. Shin
Internet-Draft ETRI
Expires: December 21, 2006 H-J. Jang
Samsung AIT
June 19, 2006
Transmission of IPv6 Packets over IEEE 802.16
draft-shin-16ng-ipv6-transmission-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on IEEE 802.16 networks. It
also specifies how to send IPv6 unicast and multicast packets over
IEEE 802.16 networks.
Shin & Jang Expires December 21, 2006 [Page 1]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
4. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Stateless Autoconfiguration and Link-Local Addresses . . . . . 8
6. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 9
7. Packet Transmission . . . . . . . . . . . . . . . . . . . . . 10
7.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1. Unicast Transmission . . . . . . . . . . . . . . . . . 11
7.1.2. Multicast Transmission . . . . . . . . . . . . . . . . 11
7.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. Unicast Transmission . . . . . . . . . . . . . . . . . 12
7.2.2. Multicast Transmission . . . . . . . . . . . . . . . . 12
7.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3.1. Unicast Transmission . . . . . . . . . . . . . . . . . 13
7.3.2. Multicast Transmission . . . . . . . . . . . . . . . . 13
7.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4.1. Unicast Transmission . . . . . . . . . . . . . . . . . 14
7.4.2. Multicast Transmission . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Shin & Jang Expires December 21, 2006 [Page 2]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
1. Introduction
Recently, broadband wireless access network is emerging for wireless
communication for user requirements such as high quality data/voice
service, fast mobility, wide coverage, etc. The IEEE 802.16 Working
Group on broadband wireless access standards develops standards and
recommended practices to support the development and deployment of
broadband wireless metropolitan area networks.
As the deployment of wireless broadband access network progresses,
users will be connected to IPv6 networks. This document specifies
the frame format for transmission of IPv6 packets and the method of
forming IPv6 link-local addresses and statelessly autoconfigured
addresses on IEEE 802.16 networks. It also specifies how to send
IPv6 unicast and multicast packets over IEEE 802.16 networks.
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].
Shin & Jang Expires December 21, 2006 [Page 3]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
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).
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.
PHS : Payload Header Suppression.
PDU : Protocol Data Unit. This refers to the data format passed from
the lower edge of the 802.16 MAC to the 802.16 PHY, which typically
contains SDU data after fragmentation, encryption, etc.
SDU : Service Data Unit. This refers to the data format passed to
the upper edge of the 802.16 MAC
Shin & Jang Expires December 21, 2006 [Page 4]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
3. Maximum Transmission Unit
IEEE 802.16 permits fragmentation and reassembly. This capabilities
are compleletely different from IP fragmentation and reassembly
process.
Fragmentation is the process by which a MAC SDU is divided into one
or more MAC PDU. This process is undertaken to allow efficient use
of availabe bandwidth relative to the QoS requirements of
connection's service flow.
The default MTU size for IPv6 packets over IEEE 802.16 is not defined
in [IEEE802.16]. Fragmentation frame size can be variable according
to the bandwidth relative to the QoS requirements of connection's
service flow. Also, it may be dependent on type of Convergence
Sublayers (CS). For example, the default MTU size for IPv6 packets
on an Ethernet CS would be 1500 octets or less. With 1400 octets as
the PMTU at the IPv6 CS, there is still enough bytes left (100) to
account for any tunneling in the Aceess Router. Mannual
configuration of each node may be required, if necessary.
Shin & Jang Expires December 21, 2006 [Page 5]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
4. Frame Format
IEEE 802.16 [IEEE802.16] defines the MAC and PHY layers for OFDM and
OFDMA-based broadband wireless access.
IEEE 802.16 PDU (Protocol Data Unit) which is the data format passed
from the lower edge of the 802.16 MAC to the 802.16 PHY, which
typically contains SDU data after fragmentation, encryption, etc.
consists of a 6-byte MAC header, various optional subheaders, and a
data payload.
The 802.16 6-byte MAC header carries the Connection Identifer (CID)
of the connection with which the PDU is associated.
It is importmant to see that there is no source or destination 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.
IEEE 820.16 SDU (Service Data Unit) which is the data format passed
to the upper edge of the 802.16 MAC.
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. The
several CSs are classified into two types of CS: IP CS and Ethernet
CS. Frame formats are different accordding to the CS types.
IPv6 packets can be transmitted in 802.16 frames. In case of IP CS
type, the data field contains the IPv6 header and payload, as shown
in Fig 1. With Ethernet CS, Ethernet header MUST be included in
802.16 frame's data field, as shown in Fig 2.
Shin & Jang Expires December 21, 2006 [Page 6]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| Type |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet |
+- -+
/ header /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2
Shin & Jang Expires December 21, 2006 [Page 7]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
5. Stateless Autoconfiguration and Link-Local Addresses
Like other IEEE 802 interfaces, the Interface Identifier for an IEEE
802.16 interface is based on the EUI-64 identifier derived from the
interface's built-in 48-bit IEEE 802 address.
The Interface Identifier is then formed from the EUI-64 by
complementing the "Universal/Local" (U/L) bit, which is the next-to-
lowest order bit of the first octet of the EUI-64.
For example, the Interface Identifier for an IEEE 802.16 interface
whose built-in address is, in hexadecimal, "34-56-78-9A-BC-DE" would
be "36-56-78-FF-FE-9A-BC-DE".
A different MAC address set manually or by software should not be
used to derive the Interface Identifier. If such a MAC address must
be used, its global uniqueness property should be reflected in the
value of the U/L bit.
An IPv6 address prefix used for stateless autoconfiguration of an
IEEE 820.16 interface must have a length of 64 bits.
The IPv6 link-local address for an IEEE 802.16 interface is formed by
appending the Interface Identifier, as defined above, to the prefix
FE80::/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 3
Shin & Jang Expires December 21, 2006 [Page 8]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
6. Address Mapping
In general, the procedure for mapping IPv6 unicast addresses into
IEEE 802.16 link-layer addresses is directly not applied as described
in [RFC1972], since IEEE 802.16 MAC header does not contain any
source or destination 802 MAC addresses.
In case of IP CS type, mapping unicast or multicast addresses to IEEE
802.16 MAC addresses is unnecessary.
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.
So, CID or multicast CID may be mapped to IPv6 unicast or multicast
addresses with TCP/UDP ports. This mapping is dependent on how to
implement it.
However, in case of Ethernet CS type, source and Ethernet addresses
are required to form the frame for Ethernet CS. In such case,
address mapping is the same as [RFC1972].
Shin & Jang Expires December 21, 2006 [Page 9]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
7. Packet Transmission
IEEE 802.16 is different from existing wireless access technologies
such as IEEE 802.11, and, while 802.16 defines the encapsulation of
an IP datagram in an IEEE 802.16 MAC payload, complete description of
IPv6 operation is not present and can benefit from IETF input and
specification.
Classification is the process by which a MAC SDU is mapped onto a
particular connection for transmission between MAC peers. This
mapping process associates a MAC SDU with a connection based on some
criteria such as protocol-specific packet information, which is
called as classification parameters according to [Section 5.2 802.16-
2004]. For IP CS, the packet may be classified by IP source/
destination addresses, etc. For Ethernet CS (IP over Ethernet CS),
the packet may be classified by Ethernet source/destination addresses
and IP source/destination addresses, source/destination port numbers,
etc. This is dependent on how to implement it.
Base Station (BS) generates the flow based on the classification (IP
CS or Ethernet CS). It also decides where to send the packet, since
IEEE 802.16 connection always ends at BS while IPv6 connection
terminates at a default router. This operation and limitation may be
dependent on subnet model.
While deploying IPv6 in the approach described in earlier sections,
there are four possible typical scenarios as discussed below
[I-D.shin-v6ops-802.16-deployment-scenarios].
7.1. Scenario A
Scenario A represents IEEE 802.16 access network deployment where a
BS is separated from a router, and a subnet consists of only single
router and multiple BSs and MSs. Current celluar-like deployment
models, WiMax and WiBro, fall within this scenario A.
+-----+
| MS1 |<------+
+-----+ |
+-----+ | +-----+ +-----+ +--------+
| MSs |<------+----| BS1 |---->| AR |----| Edge | ISP
+-----+ +-----+ +-----+ | Router +==>Network
^ +--------+
+-----+ +-----+ |
| Mss |<-----------| BS2 |--------+
+-----+ +-----+
<---> IP termination
Shin & Jang Expires December 21, 2006 [Page 10]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
Fig. 4 Scenario A
7.1.1. Unicast Transmission
o Outbound unicast packet from the MS is always forwarded on a
particular transport connection in the uplink direction to the BS.
o When BS receives the packet destined to same subnet from MS but not
to AR, the uplink CID is replaced with the corresponding downlink CID
(which may be associated with the specified Ethernet addresses in
Ethernet CS or IP addresses in Ethernet/IP CS), then forwarded to
downlink.
o Otherwise, BS decapsulates the 802.16 header and forwards the
packet to AR. In case of Ethernet CS, it will be delivered to the AR
naturally since the destination address in Ethernet header is the
AR's address. In case of IP CS, the BS is responsible to deliver it
with the proper Ethernet header. AR performs routing and then
forwards it to other BS or edge router according to the routing
result.
7.1.2. Multicast Transmission
o Outbound multicast packets from the MS are always forwarded on a
particular transport connection in the uplink direction to the BS.
o When BS receives the multicast packet with link-local scope from
MS, it sends back the packet to the downlink by using CID for
multicast. It also sends the packet to an AR after decapsulating
802.16 header.
o When BS receives the multicast packet with non-link-local scope
from MS, the packet is sent back to the downlink by using CID for
multicast. It is also sent to the AR based after decapsulating
802.16 header. In case of Ethernet CS, it will be delivered to the
AR naturally since the destination address in Ethernet header is the
multicast address. In case of IP CS, the BS is responsible to
deliver it with the proper Ethernet header. AR looks up the IPv6
multicasting routing table and then forwards the packets to other BSs
or edge router according to the result.
7.2. Scenario B
Scenario B represents IEEE 802.16 network deployment where a BS is
separated from a router, there are multiple access routers, and a
subnet consists of multiple BS and MSs. If 802.16 access networks
are widely deployed like WLAN, this scenario should be also
considered. Hot-zone deployment model falls within this scenario B.
Shin & Jang Expires December 21, 2006 [Page 11]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
+-----+ +-----+ +-----+ ISP 1
| MS1 |<-----+ +->| AR1 |----| ER1 |===>Network
+-----+ | | +-----+ +-----+
+-----+ | +-----+ |
| MS2 |<-----+-----| BS1 |--|
+-----+ +-----+ | +-----+ +-----+ ISP 2
+->| AR2 |----| ER2 |===>Network
+-----+ +-----+ | +-----+ +-----+
| Ms3 |<-----------| BS2 |--+
+-----+ +-----+
<---> IP termination
Fig. 5 Scenario B
7.2.1. Unicast Transmission
o Outbound unicast packet from the MS is always forwarded on a
particular transport connection in the uplink direction to the BS.
o If BS receives the packet destined to same subnet and to MS under
the serving BS, the uplink CID is replaced with the corresponding
downlink CID (which may be associated with the specified Ethernet
addresses in Ethernet CS or IP addresses in Ethernet/IP CS),
o Otherwise, BS decapsulates the 802.16 header and forwards the
packet onto the wired network. In case of Ethernet CS, if the packet
is destined to one of ARs, it will be delivered to the AR naturally
since the destination address in Ethernet header is the AR's address.
If the packet is destined to MS under other BS, the target BS under
which the MS exists should catch this packet instead by acting as a
proxy of the MS and send it to MS by using corresponding downlink
CID. In case of IP CS, if the packet is destined to one of ARs, the
BS is responsible to deliver it with the proper Ethernet header. If
the packet is destined to MS under other BS, the target BS should
catch this packet instead by acting as a proxy of the MS and send it
to MS by using corresponding downlink CID.
7.2.2. Multicast Transmission
o Outbound multicast packets from the MS are always forwarded on a
particular transport connection in the uplink direction to the BS.
o When BS receives the multicast packet with link-local scope from
MS, it sends back the packet to the downlink by using CID for
multicast. It also sends the packet onto the wired network after
decapsulating 802.16 header. ARs will get this, and other BSs will
receive this and send it by using CID for multicast.
o When BS receives the multicast packet with non-link-local scope
Shin & Jang Expires December 21, 2006 [Page 12]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
from MS, it sends back the packet to the downlink by using CID for
multicast. It also sends the packet onto the wired network after
decapsulating the 802.16 header. Other BSs will receive this and
send it by using CID for multicast. The multicast router receiving
this will look up the IPv6 multicasting routing table and then
forwards the packets to edge router according to the result.
7.3. Scenario C
Scenario C represents IEEE 802.16 access network deployment where a
BS is integrated with a router, composing one box in view of
implementation, and a subnet consists of only single BS/router and
multiple MSs.
+-----+
| MS1 |<------+
+-----+ |
+-----+ | +-------+ +--------+
| MS2 |<------+--->|BS/AR1 |---------| Edge | ISP
+-----+ +-------+ | Router +==>Network
+--------+
+-----+ +-------+ |
| Ms3 |<---------->|BS/AR2 |-----------+
+-----+ +-------+
<---> IP termination
Fig. 6 Scenario C
7.3.1. Unicast Transmission
o Outbound unicast packet from the MS is always forwarded on a
particular transport connection in the uplink direction to the BS/AR.
o When BS/AR receives the packet destined to same subnet from MS but
not to itself, it forwards to downlink after uplink CID is replaced
with the corresponding downlink CID (which may be associated with the
specified Ethernet addresses in Ethernet CS or IP addresses in
Ethernet/IP CS).
o When BS/AR receives the packet destined to other subnet from MS, it
forwards the packet to the edge router, which forwards the packet
accordingly based on its routing table such as IGP.
7.3.2. Multicast Transmission
o Outbound multicast packet from the MS is always forwarded on a
particular transport connection in the uplink direction to the BS/AR.
Shin & Jang Expires December 21, 2006 [Page 13]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
o When BS/AR receives the multicast packet with link-local scope from
MS, it sends back the packet to the downlink by using CID for
multicast.
o When BS/AR receives the multicast packet with non-link-local scope
from MS, BS/AR looks up the IPv6 multicasting routing table and
forwards the packets to the edge router according to the result.
7.4. Scenario D
Scenario D represents IEEE 802.16 access network deployment where a
BS is integrated with a router, composing one box in view of
implementation. In this scenario, a subnet consists of only single
BS/router and single MS. This scenario mimics the current 3GPP-like
IPv6 deployment model.
+-----+
| MS1 |<-------------+
+-----+ v
+-----+ +-------+ +--------+
| MS2 |<---------->|BS/AR1 |---------| Edge | ISP
+-----+ +-------+ | Router +==>Network
+--------+
+-----+ +-------+ |
| Ms3 |<---------->|BS/AR2 |-----------+
+-----+ +-------+
<---> IP termination
Fig. 7 Scenario D
7.4.1. Unicast Transmission
o Outbound unicast packet from MS is always forwarded on a particular
transport connection in the uplink direction to the BS/AR.
o When BS/AR receives the packet destined to same subnet (as MS) from
MS, it does not relay the packet anymore.
o Otherwise, BS/AR forwards the packet to the edge router, which
forwards the packet accordingly based on its routing table such as
IGP.
7.4.2. Multicast Transmission
Link-local and Non-link-local Multicast packet could be classified
based on destination Ethernet address in Ethernet header (Ethernet
CS) or IPv6 destination address in IP header. (IP or Ethernet CS)
o Outbound multicast packet from the MS is always forwarded on a
Shin & Jang Expires December 21, 2006 [Page 14]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
particular transport connection in the uplink direction to the BS/AR.
o When BS/AR receives the multicast packet with link-local scope from
MS, it does not forward the packet anymore.
o When BS/AR receives the multicast packet with non-link-local scope
from MS, it looks up the IPv6 multicasting routing table and forwards
the packets to the edge router according to the result.
Shin & Jang Expires December 21, 2006 [Page 15]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
8. IANA Considerations
This document requests no action by IANA.
Shin & Jang Expires December 21, 2006 [Page 16]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
9. Security Considerations
TBD
Shin & Jang Expires December 21, 2006 [Page 17]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
10. References
10.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.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
10.2. Informative References
[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.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.
[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 & Jang Expires December 21, 2006 [Page 18]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 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
Hee-Jin Jang
Samsung AIT
P.O. Box 111
Suwon 440-600
Korea
Email: heejin.jang@samsung.com
Shin & Jang Expires December 21, 2006 [Page 19]
Internet-Draft IPv6 Packet Transmission over IEEE 802.16 June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shin & Jang Expires December 21, 2006 [Page 20]
