One document matched: draft-shin-ipv6-ieee802.16-00.txt
Network Working Group M-K. Shin
Internet-Draft J-M. Moon
Expires: April 1, 2006 ETRI
September 28, 2005
Considerations of IPv6 in IEEE 802.16 Networks
draft-shin-ipv6-ieee802.16-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 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
As the deployment of IEEE 802.16 networks progresses, IPv6 will be
introduced on IEEE 802.16 networks. The characteristics of IEEE
802.16 networks put special considerations on how IPv6 used. This
document describes considerations on IPv6 adoption in IEEE 802.16
networks.
Shin & Moon Expires April 1, 2006 [Page 1]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
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 Problem Statement . . . . . . . . . . . . . . 5
3. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Neighbor Discovery for IPv6 . . . . . . . . . . . . . . . 7
3.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 7
3.1.2. Neighbor Unreachability Detection . . . . . . . . . . 7
3.1.3. Duplcate Address Detection . . . . . . . . . . . . . . 8
3.1.4. Router and Prefix Discovery . . . . . . . . . . . . . 8
3.1.5. Redirect Function . . . . . . . . . . . . . . . . . . 9
3.2. Transmission of IPv6 Packets . . . . . . . . . . . . . . . 9
3.3. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 9
3.4. IP Control/Management Protocols . . . . . . . . . . . . . 10
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Mobile IPv6 Fast Handovers . . . . . . . . . . . . . . . . 11
5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Multicast Listener Discovery . . . . . . . . . . . . . . . 12
5.2. Interworking with IP Multicast and MBS . . . . . . . . . . 12
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Security Threat Analysis . . . . . . . . . . . . . . . . . 13
7. Multiple Interface with Different Properties . . . . . . . . . 14
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Shin & Moon Expires April 1, 2006 [Page 2]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
1. Introduction
IEEE 802.16d/e [IEEE802.16][IEEE802.16e] supports MSs (Subscriber
Stations) moving at vehiclar 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 on IPv6 networks. The characteristics of IEEE
802.16 networks put special considerations on how IPv6 used. This
document describes 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. This document
classifies the issues into six groups :
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 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 interface with
differerent characteristic (e.g., WLAN) are discussed.
Shin & Moon Expires April 1, 2006 [Page 3]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
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 connection. 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 conntion 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 plurality of SS or MS.
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 & Moon Expires April 1, 2006 [Page 4]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
2. Assumptions and Problem Statement
In order to introduce IPv6 in IEEE 802.16 networks, characteristics
of IEEE 802.16 network and considerations on IPv6 adoption should be
carefully surveyed.
IEEE 802.16d [IEEE802.16] specifies the air interface, including the
medium access control layer and multiple phisical layer
specifications, of fixed broadband wireless access (BWA) systems
supporting multiple services in the 10-66 GHZ bands. Also, operation
of IEEE 802.16e [IEEE802.16e]is limited to licensed bands sutiable
for mobility below 6 GHz.
IEEE 802.16 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 characteristics of IEEE 802.16 networks are :
MS and BS links resemble a point-to-ponit link:
In PMP, there are two kinds of nodes such as MS and BS. The
downlink, from the BS to the user, operates on a central BS. MS
shares the uplink to the BS on a demand basis. The BS controls
packet transmission for the uplink and the downlink. For packet
transmission between a MS and a BS, a connection should be
established between the MS and the BS. A connection is
unidirectional and has a QoS specification. Therefore, IEEE
802.16 needs two connections for bidirectional communication. In
addition, it defines a multicast/broadcast connection for multiple
users to receive the same packets per one transmission.
MBS has different characteristics with IP multicast services:
Two types of access to multicast and broadcast services (MBS) may
be supported: single-BS access and multi-BS access. Single-BS
access is implemented over multicast and broadcast transport
connections within one BS, while multi-BS access is implemented by
transmitting data from Service Flow(s) over multiple BS. It may
be different with traditional IP multicast schemes.
CID is used to identify a connection:
In general IEEE 802.x networks, MAC address is used to generate
IPv6 addresses (link-local, global, etc.) and transmit packets at
link layer. But, In IEEE 802.16 networks, CID is used to identify
a connection to equivalent peers in the MAC of the BS and the MS.
Shin & Moon Expires April 1, 2006 [Page 5]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
Actually, existing MAC address is not necessary.
The QoS has different semantics with IP QoS (e.g., diffserv):
In IEEE 802.16 networks, a connection is unidirectional and has a
QoS specification. The QoS has different semantics with IP QoS
(e.g., diffserv). Mapping CID to Service Flow IDentifier (SFID)
defines QoS parameters of the service flow associated with that
connection. In order to interwork with IP QoS, IP QoS (e.g.,
diffserv, or flow label for IPv6) mapping should be provided.
Note that this draft does not address QoS consideration at this
phase.
Shin & Moon Expires April 1, 2006 [Page 6]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
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 links resemble a
point-to-point link; hence, the MS's only neighbor is the default
router, BS that is already known through Router Discovery which is
performed by link-layer mechanisms. Also, Neighbor Discovery packets
with a multicast detination 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 header does not include MAC addresses. Instead, in order
to identify connections to equivalent peers in the MAC of the BS and
the MS, CID is used. In certain cases, multicast CID can be provided
for in the downlink. It can be useful to tranmit efficiently link-
local multicast destination packets (e.g, Router Advertisements) from
BS to MSs. The packet transmission issues are discussed in section
3.2.
Note that considerations of Neighbor Discovery in IEEE 802.16
networks is being discussed in 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 MS and BS are not needed, since MS and
BS links resemble a point-to-point link; hence, the MS's only
neighbor is the BS that is already known through Router Discovery
which is performed by link configuration mechanisms. Actually,
Neighbor Cache is unnecessary. Also, CID is used for link-layer
transmission. Thus, CID connection state is maintained, instead of
Negibor Cache, The MS uses CID which is provideded to each connection
by BS. It must ensure the uniqueness of such connection on the link.
3.1.2. Neighbor Unreachability Detection
In general, Neighbor Unreachability Detection is used for all paths
between hosts and neighboring nodes. This fuction is used between MS
and BS, since the MS's only neighbor is the BS.
Shin & Moon Expires April 1, 2006 [Page 7]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
Neighbor Unreachability Detection portion of IPv6 Neighbor Discovery
protocol is not needed, since MS and BS don't maintain Neighbor
Cache. But MS and BS must know their neighbor reachability at IP
layer in certain cases. A BS 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 trigger mechanisms in IEEE 802.16 networks.
3.1.3. Duplcate Address Detection
Usallay, BS shall assign a prefix that is unique to an 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 need for further Duplcate Address
Detection.
However, if BS asssigns a single prefix to its all of attached MS,
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 response, a BS can perform proxy Neighbor
Advertisements for one or more other MSs. In certain this, multicast
CID can be used to to send the proxy Neighbor Advertisements to the
MSs in the downlink.
It might be dependent on implementation of IPv6 addressing/allocation
model. This issus is also discussed in section 3.3.
3.1.4. Router and Prefix Discovery
Acually, Router Discovery is already performed by link layer
configuration mechanisms. As for the Prefix Discovery, BS trasmits
Router Advertisements that contain Prefix Information to the
advertising interface whose corresponding AdvSendAdvertisements flag
is TRUE. The AdvSendAdvertisements flag must set when CID value is
set at an interface. An BS must not send Router Advertisements out
any interface that is not an advertising interface. In this case,
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 sends Router
Solicitations to its BS. In this case, MS's CID is used to identify
the MS.
Shin & Moon Expires April 1, 2006 [Page 8]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
3.1.5. Redirect Function
Redirect message is not necessary in IEEE 802.16 networks, since the
MS's only router is the BS.
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 1: IEEE 802.16 MAC header format
It is importmant to see that there is no MAC address in IEEE 802.16
MAC header format. Similar to general point-to-point links, 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.
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 certain
cases, multicast CID can be provided for in the downlink. It can be
useful to tranmit efficiently link-local multicast destination
packets in the downlink.
3.3. IPv6 Addressing
There are two possiblities to allocate IPv6 prefix in 802.16
networks. The simple method is to assign a unique prefix to an MS.
This avoids the necessity to perform Duplicate Address Detection.
Second method is to assign a single prefix to its all of attached
MSs. In this case, Duplicate Address Detection must be supported.
It might be dependent on implementation of IPv6 addressing/allocation
model. This issus should be intensively researached later, since it
will affect the protocol implementation of Duplcate Address
Detection.
Shin & Moon Expires April 1, 2006 [Page 9]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
3.4. IP Control/Management Protocols
In IPv6 protocols, there is a lot of control/management protocols
including ICMP, DHCP, SNMP, DNS, etc.
It is important to see that some of these protocols use link-local
multicast destination addresses. Within IEEE 802.16 networks, MSs
connect to their BSs via point-to-ponit links. Like some of Neighbor
Discovery protocols in IEEE 802.16, these pakcets with link-local
multicast destination addresses are transmitted as normal IEEE 802.16
MAC frames, as the same as regular unicast packets. Instead, CID is
used to identify a connection to equivalent peers in the MAC of the
BS and the MS. Also, multicast CID can be used to tranmit
efficiently these packets in the downlink.
Shin & Moon Expires April 1, 2006 [Page 10]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
4. Mobility
As for the mobility management, the movement between BSs is handled
by Mobile IPv6 [RFC3775]. Also, in certain cases (e.g., fast
handover [I-D.ietf-mipshop-fast-mipv6]) the link mobility information
must be available on Mobile IPv6.
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 Advertisement for the
rechability and the movement detection may be unnecessary becasue
IEEE 802.16 MAC provides the reachabilty by the Ranging procedure and
the movement detection by the Handoff procdure.
4.2. Mobile IPv6 Fast Handovers
In addition, IEEE 802.16 defines L2 trigger whether refresh of a IP
address is required during the handoff. Through a handoff is
occured, an additional Router Discovery procedure is not required in
case of intra-subnet handoff. Also, faster handoff may be occured by
the L2 trigger in case of inter-subnet hnadoff.
Also, IEEE 802.16g which is under-developed defines L2 trigger for
link status auch as link-up, link-down, handoff-start. These L2
trigger may make the mobile IPv6 procedure more efficient and faster.
In addition, Mobile IPv6 Fast Handover assumes the support from the
link-layer technology, but the particular link-layer information
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 & Moon Expires April 1, 2006 [Page 11]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
5. Multicast
In order to support multicast services in IEEE 802.16, Multicast
Listener Discovery [RFC2710] must be supported between MS and BS.
Also, interworking with IP multicast protocols and MBS should be
considered.
5.1. Multicast Listener Discovery
Within IEEE 802.16 networks, an MS connect to its default router, BS
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 CID can be used to transmit
efficiently query packets in 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
networks 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 broadcast service, not multicasting. MBS adheres to broadcast
service, while taditional IP multicast scheme defines multicast
routing using 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 type of services may be
roughly mapped into Source-Specific Multicast and Any-Source
Multicast, respectively.
It should be intensively researched later, since MBS will be one of
killer services in IEEE 802.16 networks.
Shin & Moon Expires April 1, 2006 [Page 12]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
6. Security
6.1. IPsec
IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may
be used within global end-to-end architecture. But, we don't have
PKIs across organization and IPsec isn't integrated with IEEE 802.16
network mobility management.
6.2. Security Threat Analysis
IEEE 802.16 networks threats may be different with IPv6 and IPv6
transition threat models [I-D.ietf-v6ops-security-overview]. It will
be discussed later.
Shin & Moon Expires April 1, 2006 [Page 13]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
7. Multiple Interface with Different Properties
If an 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 protocol inconsitancy if there are protocol issues
(modification) in IEEE 802.16 networks. Two or more different
version of protocols (e.g., NDP) may be required within 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 & Moon Expires April 1, 2006 [Page 14]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
8. Summary
+------------------------------------------------------+
| section | issues | target | wg |
+------------------------------------------------------+
| 3.1 | neighbor | protocol | ipv6 |
| | discovery | | |
+------------------------------------------------------+
| 3.2 | packet | protocol | ipv6 |
| | transmission | | |
+------------------------------------------------------+
| 3.3 | addressing | operation / | na |
| | | implementation| |
+------------------------------------------------------+
| 3.4 | control | operation / | na |
| | management | implementation| |
+------------------------------------------------------+
| 4.1 | mobile | operation / | na |
| | ipv6 | implementation| |
+------------------------------------------------------+
| 4.2 | fast | protocol | mipshop |
| | handover | | |
+------------------------------------------------------+
| 5.1 | multicast | operation / | mboned |
| | listener | implementation| |
+------------------------------------------------------+
| 5.2 | mbs | operation / | mboned |
| | interworking | implementation| |
+------------------------------------------------------+
| 6.1 | ipsec | operation / | v6ops |
| | | implementation| |
+------------------------------------------------------+
| 6.2 | threat | operation / | v6ops |
| | model | implementation| |
+------------------------------------------------------+
| 7 | multiple | operation / | na |
| | interfaces | implementation| |
+------------------------------------------------------+
Figure 2: Summary of Issues
Shin & Moon Expires April 1, 2006 [Page 15]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
9. Security Considerations
As for the security, it is briefly discussed in section 6.
Shin & Moon Expires April 1, 2006 [Page 16]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
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.
[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.
10.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-00 (work in
progress), July 2005.
[I-D.ietf-v6ops-security-overview]
Davies, E., "IPv6 Transition/Co-existence Security
Considerations", draft-ietf-v6ops-security-overview-02
Shin & Moon Expires April 1, 2006 [Page 17]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
(work in progress), July 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 & Moon Expires April 1, 2006 [Page 18]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
Authors' Addresses
Myung-Ki Shin
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 4847
Email: mkshin@pec.etri.re.kr
Jung-Mo Moon
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 6748
Email: jmmoon@etri.re.kr
Shin & Moon Expires April 1, 2006 [Page 19]
Internet-Draft IPv6 in IEEE 802.16 Networks September 2005
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 (2005). 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 & Moon Expires April 1, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 04:49:06 |