One document matched: draft-lee-ndp-ieee802.16-00.txt
Network Working Group J-C. Lee
Internet-Draft ETRI
Expires: April 18, 2006 Y-H. Han
Samsung AIT
M-K. Shin
ETRI
H-J. Jang
Samsung AIT
H-J. Kim
ETRI
October 15, 2005
Considerations of NDP over IEEE 802.16 Networks
draft-lee-ndp-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 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IEEE 802.16 issued standards for the new PHY and MAC for providing
Lee, et al. Expires April 18, 2006 [Page 1]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
broadband wireless access network. It is characterized by very high
data rates and wider range of which technologies are different from
existing wireless access technologies such as IEEE 802.11 or 3G.
Accordingly, the use of IPv6 over IEEE 802.16 network is currently
undefined. There are several issues to be considered in deploying
IPv6 over IEEE 802.16 network. Among them, this document will
describe issues related to neighbor discovery protocol (NDP) over
IEEE 802.16 networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Problem Statements . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Issues regarding ND protocol itself . . . . . . . . . 4
1.3.2. Architectural and Operational Issues . . . . . . . . . 6
1.4. Specification of Requirements . . . . . . . . . . . . . . 8
2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Case 4: BS and router in one box + Prefix to subnet . . . 9
2.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 11
2.1.3. Router and Prefix Discovery . . . . . . . . . . . . . 11
2.1.4. Redirect function . . . . . . . . . . . . . . . . . . 12
3. The use of ND messages . . . . . . . . . . . . . . . . . . . . 13
3.1. Router Solicitation Message . . . . . . . . . . . . . . . 13
3.2. Router Advertisement Message . . . . . . . . . . . . . . . 13
3.3. Neighbor Solicitation Message . . . . . . . . . . . . . . 14
3.4. Neighbor Advertisement Message . . . . . . . . . . . . . . 15
3.5. Redirect Message . . . . . . . . . . . . . . . . . . . . . 15
4. Conceptual Model of a Host . . . . . . . . . . . . . . . . . . 17
4.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 17
5. Summary Matrix . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Case 4: BS and router in one box + Prefix to subnet . . . 18
6. Secuirty Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Lee, et al. Expires April 18, 2006 [Page 2]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
1. Introduction
The IEEE802.11 network has driven the revolution of wireless
communication, but as the more people use it, more of its limitations
like short range or lack of mobility support have been revealed.
Compared with IEEE802.11 network, IEEE802.16 supports enhanced
features like wider range and mobility. Thus, it is expected that
IEEE802.16 network would be the next step of IEEE802.11 network.
The IEEE802.11 MAC protocol is almost same as the IEEE802.3 protocol
with the exception of being able to be used over an air medium.
Thus, most of the existing layer 3 protocols can be used without any
modification. The structure of IEEE802.16 protocol is, however, much
different from the IEEE802.11 protocol. Therefore, it is needed to
consider if IPv6 runs well over IEEE802.16 networks.
There are several issues to be considered in deploying IPv6 over
IEEE802.16 network [I-D.shin-ipv6-ieee802.16]. Among them, this
document will describe issues about the Neighbor Discovery Protocol
[RFC2461].
1.1. Scope of this Document
The considerations described in this document are only applied to the
subnet composed of BS and MS(s) attached to that BS over the
IEEE802.16 network.
We are considering two BS deployment cases and two addressing cases
each, but only one scenario that adopts BS integrated with router
function and allocates a same prefix to all MS(s) attached to one BS
would be considered in this version of draft.
1.2. Terminology
802.16 subnet:
The subnet composed of MS(s) attached to the same BS. This
terminology is only used in this document.
SS:
Subscriber Station. A general equipment set providing
connectivity between subscriber equipment and a BS.
MS:
Lee, et al. Expires April 18, 2006 [Page 3]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
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 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.
NS:
Neighbor Solicitation message
NA:
Neighbor Advertisement message
RS:
Router Solicitation message
RA:
Router Advertisement message
and all other terminologies declared in [RFC2461]
1.3. Problem Statements
1.3.1. Issues regarding ND protocol itself
Sending to and Receiving from multicast address:
1. The 802.16 MAC header doesn't include a MAC address, so we
can't send to or receive from multicast address as the way how
Lee, et al. Expires April 18, 2006 [Page 4]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
802.3 and 802.11 do.
2. How to join multicast addresses (all-nodes multicast address,
solicited-node multicast address) required for DAD? or is
there any way to send or receive multicast packet without
joining multicast address?
Address autoconfiguration:
1. Creation of link-local address (requires DAD): basically, IPv6
node creates link-local address for use on a single link.
Link-local addresses are designed to be used for addressing on
a single link for purposes such as automatic address
configuration, neighbor discovery, or when no routers are
present. In order to create link-local addresses, DAD should
be done to guarantee the uniqueness of the link-local
addresses in a link. This DAD MUST take place on all unicast
addresses, regardless of whether they are obtained through
stateful, stateless or manual configuration [RFC2462]. The
problem in processing DAD is that the procedure for DAD uses
NS message sent to solicited-node multicast address and NA
message sent to all-node multicast address.
2. Creation of global scope address (requires DAD): IPv6 host can
create its global-scope addresses by appending an interface
identifier to a prefix obtained from RA message. Even in this
case, DAD should be done with the same reason as link-local
address case.
Conceptual sending algorithm:
1. Address Resolution (solicited-node multicast address): When
sending a packet to a destination, a node uses a combination
of the Destination Cache, the Prefix List, and the Default
Router List to determine the IP address of the appropriate
next hop, an operation known as "next-hop determination".
Once the IP address of the next-hop node is known, the sender
examines the Neighbor Cache for link-layer information about
that neighbor. If no entry exists, the sender creates new
one, and then initiates Address Resolution. For multicast-
capable interfaces Address Resolution consists of sending a NS
message destined for solicited-node multicast address and
waiting for a NA message. There are two problems with this
issues. The one is whether Address Resolution is needed or
not over 802.16 network and the other is if Address Resolution
is needed, how we send NS message destined for solicited-node
multicast address.
Lee, et al. Expires April 18, 2006 [Page 5]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
2. Neighbor Unreachability Detection: whenever an IPv6 node
accesses its Neighbor Cache entry while transmitting a unicast
packet, the sender checks Neighbor Unreachability Detection
related information according to NUD algorithm. If there is
no need to do Address Resolution, NUD is not needed.
Router and Prefix discovery:
1. Sending Router Solicitation message to all-router multicast
address: Router Discovery is used to locate neighboring
routers as well as learn prefixes and configuration parameters
related to address autoconfiguration. This procedure consists
of sending RS message to All-routers multicast address and
receiving RA message. The problem is how we send RS message
destined for all-routers multicast address.
2. Set the 'L' bit in Prefix Information option or not? (on-link
determination): The Prefix Information option has 'L' bit
indicating this prefix can be used for on-link determination.
As what mentioned before we have two policies on allocating
prefixes to the MS(s). The determination of setting 'L' bit
is dependent on this policy.
Redirect function
Is it needed in 802.16 network environment?
1.3.2. Architectural and Operational Issues
We consider two types of the Base Station deployment mode and two
policies on how we allocate prefixes to the Mobile Station.
IEEE 802.16 Base Station Deployment Modes
We describe two possible deployment architectures of IEEE 802.16
network. Figure 1 and 2 show the two cases.
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 SS and BS. In this case, the methods of IPv6
adoption to IEEE 802.16 may depend on the underlying network
Lee, et al. Expires April 18, 2006 [Page 6]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
architecture between BSs and router.
/-------------------------------------\
| Backbend Network |
\-------------------------------------/
| |
/-----------\ /-----------\
| Router1 | | Router2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 1. IEEE 802.16 deployment architecture with BS and
Router in separated boxes
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.
/------------------\
| Backbend Network |
\------------------/
/ \
/ \
/ \
--------- ---------
| Router1 | | Router2 |
| BS1 | | BS2 |
--------- ---------
Figure 2. IEEE 802.16 deployment architecture with BS and
Router in one box.
IPv6 ND Prefix Allocation Policies
There are two possible addressing schemes as follows.
1. Prefix to SS: [RFC3314] 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
Lee, et al. Expires April 18, 2006 [Page 7]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
recommendation can be also applied to IEEE 802.16 network
system if it is reasonable to the given usage scenario. In
such case, many IPv6 functionalities can be implemented
without difficulty.
2. Prefix to Subnet: Different usage scenario such as 'Hot zone'
would not allow [RFC3314] 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. (*
hot zone: an area served by one BS, similar meaning to Hotspot
in 802.11)
As a result of above combinations, we can consider the following four
cases for the scenarios of IPv6 adoption to IEEE 802.16 networks.
+--+---------------------------+------------------+
| | Deployment | Addressing |
+--+---------------------------+------------------+
| 1| Router separation from BS | Prefix to SS |
+--+---------------------------+------------------+
| 2| Router separation from BS | Prefix to subnet |
+--+---------------------------+------------------+
| 3| BS and router in one box | Prefix to SS |
+--+---------------------------+------------------+
| 4| BS and router in one box | Prefix to subnet |
+--+---------------------------+------------------+
*** Among above cases we will only consider case 4 in this version of
draft.
1.4. 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].
Lee, et al. Expires April 18, 2006 [Page 8]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
2. Protocols
2.1. Case 4: BS and router in one box + Prefix to subnet
2.1.1. Addresses
2.1.1.1. link-local address
Basically, the procedure to create link-local address follows
[RFC2462]. 802.16 interface also has 48bits MAC address as other
802.x family [IEEE802.16]. Therefore, this 48bits MAC address of
802.16 interface can be used for making interface identifier.
Duplicate Address Detection:
Usually the link between MS and BS resembles a point-to-point
link, hence if BS allocates different prefix to each MS there is
no need to do DAD. But if BS allocates unique prefix to MS(s)
belong to 802.16 subnet, DAD should be done. This case will be
described in Section 2.1.2.1 later.
2.1.1.2. Multicast address
ND has several multicast addresses used for its service, but 802.16
MAC header doesn't include MAC address, and thus this makes it harder
to deliver and receive ND multicast packet.
In 802.3, a corresponding MAC address to the each link-local
multicast address [RFC2464] is maintained and the layer 2 of each
node can recognize the multicast packets. Thus, the delivery of the
multicast packets is done in a distributed manner, but 802.16 does
not manage such MAC address for the multicast, so the multicasting
needs to be handled centrally.
In spite of this limitation, we can use ND service without big
modification of ND protocol by using the characteristics of 802.16
network.
all-nodes multicast address (link-scoped)
All IPv6 nodes which have unicast address should join this
multicast address. There are two cases to send packets to all-
nodes multicast destination; the one is to send Unsolicited Router
Advertisement (RA) message to MS(s) and the other is to send
Unsolicited Neighbor Advertisement (NA) message to the adjacent
neighbor.
Lee, et al. Expires April 18, 2006 [Page 9]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
Unsolicited RA message: The BS knows MS(s) list attached to
itself, hence it can send Unsolicited Router Advertisement
message to MS(s) in a unicast manner.
Unsolicited NA message: This case could be happen in case that
link-layer address of a node is changed. *** Needs further
study... ***
solicited-node multicast address (link-scoped)
All IPv6 nodes which have unicast address should join the
corresponding multicast address. This address is used for address
resolution, but usually there is no need to do address resolution
over 802.16 network in scenario 4, because the next hop of MS is
always BS. But there might be some other cases under
consideration.
all-routers multicast address (link-scoped)
This address is used in Router Solicitation message. The MS can
send this message to the adjacent router without support of
multicast because its only neighbor is BS.
To support the multicast communication, the BS can manage the
multicast group and handle the delivery in a central manner. When
the BS receives the multicast packets, it can apply the selective
decision to optimize the airlink resources based on the type of
multicast packets.
1. Some types of multicast traffic may be filtered off and be
dropped by the BS.
2. Some types of multicast traffic such as all-nodes multicast may
be delivered in a unicast manner to all MSs.
3. Some types of traffic such as solicited-node or all-routers
multicast may be delivered in a unicast manner to the some of
nodes (its members).
4. Some types of traffic may be forwarded to a specific node.
5. Some types of traffic may be delivered by using a shared CIDs.
In case of 1), for example, the BS can drop the NS for DAD, which
will be mention in detail in Section 2.1.2.1. In case of 2), the BS
knows MS list attached to itself, hence it can send Unsolicited RA/NA
to MS(s) by using basic connection allocated to each MS. For 3), it
is necessary for the BS to manage each multicast membership. In case
Lee, et al. Expires April 18, 2006 [Page 10]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
of 4), if the BS can predict the respondent of the multicast packet
based on the collected information during network (re)entry or
through some ways, it may forward the multicast packet to the
specific node. For 5), the BS can allocate one or more shared
Connection IDs (CIDs) across all or some MSs, which enables the BS to
send only a single copy of the packet and all the members of a single
multicast group can receive it. In addition to the membership
knowledge, the BS needs to define the several kinds of CIDs, and be
able to map the multicast addresses to the corresponding 802.16 CIDs.
This approach seems to be similar to [RFC2464].
The BS may use the mix of 1)~5) for the efficiency of air resources.
For instance, it can use the approaches of 1), 4) and 5) together.
However, how to implement the assignment of CIDs and the mapping of
CIDs depends on the BS implementation and is out of scope of this
document.
2.1.1.3. Anycast address
Same as the unicast case.
2.1.2. Address Autoconfiguration
The IPv6 host can create link-local unicast address and global-scope
unicast address in a stateless manner [RFC2462]. Before completing
address autoconfiguration procedure in Section 2.1 scenario, the IPv6
host must do DAD to check uniqueness of address. In this scenario,
DAD operates as follows.
2.1.2.1. Duplicate Address Detection (DAD)
There might be various implementation techniques for DAD
implementation over 802.16 networks. When the BS has the list of all
MS's IP addresses on that link, it can check whether the target
address in NS is unique or not. If unique, it may be filtered off as
described 1. of Section 2.1.1.2, otherwise the BS may forward the
packets.
o As described in Section 2.1.1.2 before, MS can't send NS message
in a multicast manner. Instead, the MS sends NS message to BS
directly.
o The BS acts in a manner descried Section 2.1.1.2.
2.1.3. Router and Prefix Discovery
Mainly described in Section 2.1.1.2.
Lee, et al. Expires April 18, 2006 [Page 11]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
2.1.3.1. Unsolicited Router Advertisement
The BS would send Unsolicited RA through interface(s) whose
AdvSendAdvertisements flag is set TRUE. This case is also described
in Section 2.1.1.2.
2.1.4. Redirect function
Redirect message shall not be used since MS's next-hop is always BS
and there is no better choice.
Lee, et al. Expires April 18, 2006 [Page 12]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
3. The use of ND messages
3.1. Router Solicitation Message
IP fields:
Source address
ip address assigned to sending interface or unspecified
address(::)
Destination address
all-router multicast address (ff02::2, link-local scope)
Valid options:
Source link-layer address
"The link-layer address of the sender, if known. MUST NOT be
included if the Source Address is the unspecified address.
Otherwise it SHOULD be included on link layers that have
addresses." [RFC2461]
A 802.16 interface has 48bits MAC address, but it is not be
used in sending or receiving packets except for initialization
process. Therefore, this option will not be included.
3.2. Router Advertisement Message
The transmission of periodic RAs may not be proper in 802.16 networks
in view of resource efficiency. When the MS is attached to link, the
BS may begin to transmit RAs. Once the configurable number of RAs is
sent, the BS may not send more RAs to limit the multicast packets.
The BS can reply with the RA only in response to RS.
IP fields:
Source address
link-local address assigned to the interface from which this
message is sent.
Destination address
Lee, et al. Expires April 18, 2006 [Page 13]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
source address of an invoking router solicitation message or
all-nodes multicast address(ff02::1, link-local scope)
ICMP fields:
Router Lifetime
"...0 indicates that the router is not a default router and
SHOULD NOT appear on the default router list..."[RFC2461]. BS
always acts as default router of MS, hence this field should
not be set 0.
Possible options:
Prefix Information
In cases that adopt IPv6 ND Prefix Allocation Policy 2, each MS
comprising 802.16 subnet with same prefix advertised by BS as
other MS(s) is not on-link with each other. Therefore set 'L'
bit off.
3.3. Neighbor Solicitation Message
IP fields:
Source address
address assigned to the interface from which this message is
sent or unspecified address (::, in case of DAD)
Destination address
solicited-node multicast address (ff02:0:0:0:0:1:ffxx:xxxx,
link-local scope, in case of address resolution) or target
address (in case of DAD)
Possible options:
Source link-layer address
"...Otherwise, on link layers that have addresses this option
MUST be included in multicast solicitations and SHOULD be
included in unicast solicitations." [RFC2461]. Does not
include this option with same reason as Section 3.1.
Lee, et al. Expires April 18, 2006 [Page 14]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
3.4. Neighbor Advertisement Message
neighbor solicitation messages shall be discarded by BS except if it
is part of NUD.
IP fields:
Source address
address assigned to the interface from which the advertisement
is sent.
Destination address
for solicited advertisements:
- source address of an invoking neighbor solicitation
- all-nodes multicast address (if the source address of
solicitation message is ::)
for unsolicited advertisement:
- all-nodes multicast address (ff02::1, link-local scope)
Possible options:
Target link-layer address
"...This option MUST be included on link layers that have
addresses when responding to multicast
solicitations..."[RFC2461]. Does not include this option with
same reason as Section 3.1 and the next hop of MS is always BS,
hence this option is meaningless except for Unsolicited
Neighbor Advertisement.
3.5. Redirect Message
This message shall not be used because MS's next-hop is always BS and
there is no better choice.
IP fields:
Source address
Lee, et al. Expires April 18, 2006 [Page 15]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
link-local address assigned to the interface from which this
message is sent.
Destination address
source address of the packet that triggered the redirect.
Lee, et al. Expires April 18, 2006 [Page 16]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
4. Conceptual Model of a Host
4.1. Conceptual Data Structures
Neighbor Cache:
Usually the MS has neighbor caches, but it might be empty as
described in Section 2.1.1.2. This also means that there is no
need to do NUD. If the MS should do address resolution by some
other reason, its next hop would be BS and the neighbor cache
entry would be filled with the MAC address of the BS. In this
case, MS would do NUD.
Even if there are neighbor caches, it would not be used in sending
procedure.
Destination Cache: No special issue.
Prefix List: No special issue.
Default Router List: No special issue.
Lee, et al. Expires April 18, 2006 [Page 17]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
5. Summary Matrix
5.1. Case 4: BS and router in one box + Prefix to subnet
+--------+-----------+--------+--------+---------+--------+---+---+
| | Router |Address | | | | | |
| |& Prefix | Auto- |Address | Next-hop| Packet | | |
| |& Parameter|Config- |Resolut-|Determin-|Transmi-|NUD|DAD|
| |discovery |uration |ion |ation |ssion | | |
+--------+-----------+--------+--------+---------+--------+---+---+
| RS | O | O | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
| RA | O | O | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
| NS | | | X(O) | | | O | O |
+--------+-----------+--------+--------+---------+--------+---+---+
| NA | | | X(O) | | | O | O |
+--------+-----------+--------+--------+---------+--------+---+---+
|Redirect| | | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
|Neighbor| | | | | | | |
|cache | | | | | O | | |
+--------+-----------+--------+--------+---------+--------+---+---+
|Destina-| | | | | | | |
|tion | | | | O | O | | |
|cache | | | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
|Prefix | | | | | | | |
|List | | | | O | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
|Default | | | | | | | |
|Router | | | | O | O | | |
|List | | | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
| DAD | | O | | | | | |
+--------+-----------+--------+--------+---------+--------+---+---+
| NUD | | | | | X(O) | | |
+--------+-----------+--------+--------+---------+--------+---+---+
o Axis X: Operations.
o Axis Y: Messages, Data Structures, and Operations used by
operations.
o O : a Message or Data Structure is used.
o X(O): Basically a Message or Data Structure is not used, but used
under special condition.
Lee, et al. Expires April 18, 2006 [Page 18]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
6. Secuirty Considerations
Until now there is no special security consideration found for these
issues and most of the security considerations might follow
[RFC2461].
Lee, et al. Expires April 18, 2006 [Page 19]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
7. References
7.1. Normative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[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.
7.2. Informative References
[I-D.shin-ipv6-ieee802.16]
Shin, M., "Scenarios and Considerations of IPv6 in IEEE
802.16 Networks", draft-shin-ipv6-ieee802.16-01 (work in
progress), October 2005.
Lee, et al. Expires April 18, 2006 [Page 20]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
Authors' Addresses
Joo-Chul Lee
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-350
Korea
Fax: +82 42 861 5404
Email: rune@etri.re.kr
Youn-Hee Han
Samsung AIT
P.O. Box 111
Suwon 440-600
Korea
Fax:
Email: yh21.han@samsung.com
Myung-Ki Shin
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-350
Korea
Fax: +82 42 861 5404
Email: mkshin@pec.etri.re.kr
Hee-Jin Jang
Samsung AIT
P.O. Box 111
Suwon
Korea
Fax: +82 31 280 9569
Email: heejin.jang@samsung.com
Lee, et al. Expires April 18, 2006 [Page 21]
Internet-Draft NDP over IEEE 802.16 Networks October 2005
Hyoung-Jun Kim
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-350
Korea
Fax: +82 42 861 5404
Email: khj@etri.re.kr
Lee, et al. Expires April 18, 2006 [Page 22]
Internet-Draft NDP over IEEE 802.16 Networks October 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.
Lee, et al. Expires April 18, 2006 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:47 |