One document matched: draft-lee-ndp-ieee802.16-01.txt
Differences from draft-lee-ndp-ieee802.16-00.txt
Network Working Group J-C. Lee
Internet-Draft ETRI
Expires: August 5, 2006 S. Madanapalli
Samsung ISO
H-J. Jang
Samsung AIT
February 2006
NDP over IEEE 802.16 Networks
draft-lee-ndp-ieee802.16-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 August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
IEEE 802.16 issued the new standards for PHY and MAC providing
broadband wireless access network. Currently, it is being developed
under the assumption that IPv4 is used over it and the use of IPv6
over IEEE 802.16 networks has not been considered yet. Hence, this
draft describes several problems in running NDP over IEEE 802.16
Lee, et al. Expires August 5, 2006 [Page 1]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
networks and presents some proposed solutions for those problems.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Specification of Requirements . . . . . . . . . . . . . . 4
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Issues Regarding IEEE 802.16 Architecture . . . . . . . . 5
2.1.1. IEEE 802.16 Network Aspect Issues . . . . . . . . . . 5
2.1.2. IEEE 802.16 Node Aspect Issues . . . . . . . . . . . . 7
2.2. Issues Regarding NDP . . . . . . . . . . . . . . . . . . . 8
2.2.1. Address Autoconfiguration . . . . . . . . . . . . . . 8
2.2.2. Address Resolution . . . . . . . . . . . . . . . . . . 9
2.2.3. Conceptual Sending Algorithm . . . . . . . . . . . . . 9
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Multicast Support . . . . . . . . . . . . . . . . . . . . 11
3.2. Solution CASE 1 . . . . . . . . . . . . . . . . . . . . . 12
3.3. Solution CASE 2 . . . . . . . . . . . . . . . . . . . . . 13
3.4. Solution CASE 3 . . . . . . . . . . . . . . . . . . . . . 14
3.5. Solution CASE 4 . . . . . . . . . . . . . . . . . . . . . 15
4. Secuirty Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Lee, et al. Expires August 5, 2006 [Page 2]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
1. Introduction
The IEEE 802.16 specifies a new PHY and MAC for providing broadband
wireless access networks. This protocol is a connection-oriented
technology without bi-directional native multicast support that
Ethernet can provide. Since IPv6 operation is based on multicast
such as router advertisement, this characteristic can be a major
reason to prevent IPv6 from being deployed over IEEE 802.16 networks
immediately. To deploy IPv6 over IEEE 802.16 networks, we also have
to consider different kinds of convergence sublayers and subnet
models
To deploy IPv6 over IEEE 802.16 networks, we also have to consider
convergence sublayers and several subnet models. These factors make
problems more complicated. We will describe these problems in more
detail later.
There are several feasible deployment scenarios [I-D.shin-ipv6-
ieee802.16] that we have to consider when we introduce IEEE 802.16
networks. These deployment scenarios may have close relation with
problems, thus we will describe proposed solution for these problems
according to the each scenario.
This problems and solution described in this document may also be an
input to other standard organization like WiMax.
1.1. 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 connection identifier (CID). All traffic is
carried on a connection.
Lee, et al. Expires August 5, 2006 [Page 3]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
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.
CS:
Convergence Sublayer. CS provides any transformation or mapping
of external network data, received through the CS service access
point (SAP), into MAC SDUs received by the MAC Common Part
Sublayer (CPS) through the MAC SAP.
PDU:
Protocol Data Unit. The data unit exchanged between peer entities
of the same protocol layer. On the downward direction, it is the
data unit generated for the next lower layer. On the upward
direction, it is the data unit received from the previous lower
layer.
MBS:
Multicast and Broadcast Service. Some globally defined service
flows which may carry broadcast or multicast information that
should be delivered to a plurality of SS or MS.
and all other terminologies defined in [RFC2461]
1.2. 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 August 5, 2006 [Page 4]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
2. Problem Statements
The problems can be classified into two categories like "issues
regarding IEEE 802.16 architecture" and "issues regarding NDP".
2.1. Issues Regarding IEEE 802.16 Architecture
MS, BS, AR comprise IEEE 802.16 networks. When we establish IPv6
networks over IEEE 802.16 technology, we can assume several
architectural variations. NDP considerations for IEEE 802.16
networks may be affected by these variations.
2.1.1. IEEE 802.16 Network Aspect Issues
IEEE 802.16 connection always ends at BS, which is connected to AR.
In this situation, we can make BS integrated with AR or separated
from AR, and make the sebnet comprised of one BS & MSs or several BSs
& MSs.
2.1.1.1. Subnet Models
1. A Prefix per each MS: [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
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. A Prefix for all MSs attached to BS(s) : Different usage scenario
such as 'Hot zone' [I-D.shin-v6ops-deployment-scenarios] 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.
2.1.1.2. BS Architecture
1. BS and AR are in one box: This case represents an alternative
IEEE 802.16 network deployment where a BS is integrated with a
AR. A subnet may consist of a router and a BS. In this case,
both of <subnet model>.1 and <subnet model>.2 are possible.
Lee, et al. Expires August 5, 2006 [Page 5]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
/------------------\
| Backbend Network |
\------------------/
/ \
/ \
/ \
--------- ---------
| Router1 | | Router2 |
| BS1 | | BS2 |
--------- ---------
Figure 3. BS and AR are in one box
2. BS is separated from AR: 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. With this BS architecture, <subnet model>.1 can't be
applied to IPv6 over IEEE 802.16 networks and if ethernet CS is
used a L2 tunnel should be used between BS and AR.
/-------------------------------------\
| Backbend Network |
\-------------------------------------/
| |
/-----------\ /-----------\
| Router1 | | Router2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 4. BS is separated from AR
2.1.1.3. Multicast Support
IEEE 802.16 is a point-to-multipoint connection oriented technology
without bi-directional native multicast support. This prevents IPv6
nodes from multicasting like [RFC2464] without any explicit support
on network side. Most of NDP functions depend on the multicast
support from the lower layer. So for NDP to function normally on
IEEE 802.16 networks, there must be some explicit support for
multicasting from network side. More detailed solution for multicast
support will be dealt in Section 3.1.
The consequence of the lack of optimal multicast supports in IEEE
802.16 networks is that any IP layer protocol like NDP, DHCPv6, IPv4
Lee, et al. Expires August 5, 2006 [Page 6]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
ARP depending on the lower layer multicast support may not function
normally.
2.1.2. IEEE 802.16 Node Aspect Issues
IEEE 802.16 MAC includes service-specific Convergence Sublayers (CS)
that interface to higer layers. Some NDP operations may have
dependency on the CS that IEEE 802.16 node adopts.
2.1.2.1. Convergence Sublayer
Currently, IEEE 802.16 provides two CS: the asynchronous transfer
mode (ATM) CS and the packet CS. The ATM CS is used for ATM
services, the packet CS is used for transport for all packet-based
protocols such as IP, PPP, and ethernet. The primary job of CS is to
perform classification of higher-layer PDUs [IEEE802.16].
In this document, only the packet CS would be considered. The packet
CS includes ethernet CS and IP CS.
IPv6 CS
In case of IPv6 CS, its classification parameters are IPv6 header
and transport header. If MS adopts IPv6 CS, some kind of tunnel
between BS and AR may be needed to transfer IPv6 packets from MS
to AR in case that BS is separated from AR. Address resolution
process is trivial in case of IPv6 CS, because there is no need to
make ethernet header.
Ethernet CS
When ethernet CS is used, the following parameters are used for
classification: destination MAC address, source MAC address,
ethertype. For IP over IEEE 802.3/ethernet, IP headers may be
included in classification.
In case of ethernet CS, IP packet from MS can be delivered to AR
without any help of tunnel even though BS is separated from AR.
IEEE 802.16 MAC header doesn't include 48bits MAC address, but
address resolution process may be needed if MS adopts ethernet CS.
The more details about this would be described in solution
section.
For clarification, the support of ethernet CS doesn't mean IEEE
802.3/ethernet emulation. multicast/broadcast frame can not be
processed at the IEEE 802.16 MAC layer.
Lee, et al. Expires August 5, 2006 [Page 7]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
2.1.2.2. Transport Connection for NDP Message Transmission
At MS initialization, two pairs of management connections (uplink/
downlink) shall be established between the MS and the BS and the
third pair of management connections may be optionally generated.
The basic connection is used to exchange short, time-urgent MAC
management messages. The primary management connection is used to
exchange longer, more delay-tolerant MAC management messages.
Finally, the secondary management connection is used to transfer
delay tolerant, standards-based messages like DHCP, TFTP, SNMP etc.
But it is unclear that the secondary management connection can be
used to transfer NDP messages. Thus, MS and BS are required to set
up transport connections for transfering NDP messages.
2.2. Issues Regarding NDP
Basically, the lack of native multicast support in IEEE 802.16
networks makes it harder for NDP to function normally and some
architectural characteristics of IEEE 802.16 networks may affect the
detailed operations of NDP.
2.2.1. Address Autoconfiguration
Global/site-local address
The explicit multicast support is required to forward unsolicited
router advertisement message (RA) to all MSs which belong to a
same subnet. This solution would be described in Section 3.1 in
detail.
Prefix Assignment
Prefix assignment has dependency on BS architecture and subnet
model. If BS is separated from AR, <subnet model>.1 is impossible
because AR have no capability to assign different prefix per each
MS (i.e. AR is normal router). <subnet model>.1 and <subnet
model>.2 are possible if BS and AR are in one box.
If a prefix is shared among MSs then the subnet may consist of one
or more BS(s) and multiple MSs (<subnet model>.2). In this model,
a MS assumes that every other MS which shares same prefix are on-
link, thus it would try to resolve the L2 address for the on-link
prefixes. But direct communication using L2 address between two
MSs may not be possible because of IEEE 802.16 network's
structural reason. One way to prevent this situation is to
advertise a prefix with 'L' bit reset.
Lee, et al. Expires August 5, 2006 [Page 8]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
DAD procedure
Duplicate Address Detection must take place on all unicast
addresses, regardless of whether they are obtained through
stateful, stateless or manual configuration [RFC2462].
DAD procedure has some dependency on subnet model described in
Section 2.1.1.1. If a prefix is assigned to each MS (<subnet
model>.1) then the subnet consists of only a MS and a BS. Thus,
there is no chance to collide with other address and hence DAD
procedure seems to be trivial. If MSs share a prefix (<subnet
model>.2) then DAD procedure should not be ignored, but DAD in
IEEE 802.16 requires explicit multicast support. This problem can
be solved through the solution described in Section 3.1 or proxy
DAD. In proxy DAD, each BS/AR maintains the list of all addresses
that are currently used and then BS/AR does proxy DAD on behalf of
each address owner.
2.2.2. Address Resolution
Address resolution has dependency on CS and subnet model.
In case of ethernet CS, if a prefix is assigned to each MS (<subnet
model>.1) address resolution is trivial (the next-hop of each MS's
always BS/AR). If a prefix with 'L' bit set is shared among MSs
(<subnet model>.2), address resolution is required.
In case of IPv6 CS, address resolution is trivial. The next-hop of
each MS is always BS/AR (<BS architecture>.1) or AR(<BS
architecture>.2).
2.2.3. Conceptual Sending Algorithm
To send an IPv6 packet to a destination, the IPv6 node determines its
next-hop firstly (Next hop Determination) and looks up the L2 address
of next-hop in neighbor cache (Address Resolution) and finally send
the IPv6 packet to the next-hop. Once a neighbor cache entry is
made, whenever it is referred its reachability is checked (Neighbor
Unreachability Detection).
Next Hop Determination
It depends on subnet model. In case of <subnet model>.1, the
next-hop of the MS is always BS/AR. In case of <subnet model>.2,
if MSs share a prefix with 'L' bit set the next-hop determination
would be performed as usual. If MSs share a prefix with 'L' bit
off, the next-hop of the MS is always BS/AR or AR.
Lee, et al. Expires August 5, 2006 [Page 9]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
Neighbor Cache
The maintenance of neighbor cache depends on CS and subnet model.
In case of IPv6 CS, address resolution is not strongly required
because there is no ethernet header and hence the next-hop of MS
is always BS/AR or AR. If the MS adopts ethernet CS and it shares
a prefix with 'L' bit set with other MSs (<subnet model>.2), the
address resolution is required and neighbor cache would be
maintained.
Neighbor Unreachability Detection
If MSs share a prefix with 'L' bit set, NUD would be performed as
usual and if 'L' bit off or a prefix is assigned to each MS, the
NUD would be required only for BS/AR or AR.
Lee, et al. Expires August 5, 2006 [Page 10]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
3. Solutions
In this section, we introduce a proposed multicast support mechanism
and describe solution per feasible deployment scenario [I-D.shin-
v6ops-deployment-scenarios]
3.1. Multicast Support
As mentioned before, some NDP functions need explicit multicast
support to function normally over IEEE 802.16 networks. Hence we
introduce the solution for multicast support in IEEE 802.16 networks.
Mutiple Unicast
Multiple unicast is the approach that is very simple but uses more
network resources. The BS maintains the list of members which
join a specific multicast address and if the BS receives a packet
destined for the specific multicast address, it sends a copy of
the packet as many times as the number of members.
Multicast CID
IEEE 802.16 provides support for downlink multicast from BS to MSs
(MBS). Multicast CID approach uses this feature of IEEE 802.16.
Multicast CID is a CID shared among the member nodes of a
multicast group. To transmit multicast packets over the link with
multicast CID, each CID should be shared by each multicast group
member prior to packet transmission. For NDP, three multicast
CIDs are needed (all-nodes multicast address, all-routers
multicast address, solicited-node multicast address).
The simple operation procedure of this approach is as follows.
For more detailed procedure, refer to [I-D.jang-16ng-llm]:
1. Each MS joins following CIDs at initialization stage.
+ all-nodes multicast CID: all MSs join the all-nodes
multicast group by generating the predefined CID for this
group.
+ solicited-node multicast CID: all MSs make its solicit-node
multicast by generating the corresponding CID for its
group.
+ all-routers multicast CID: all MSs join the all-routers
multicast group by generating the predefined CID for this
group if it acts as a router
Lee, et al. Expires August 5, 2006 [Page 11]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
2. MS may send packets destined for all-node multicast, all-
router multicast, solicited-node multicast to BS or AR may
send packets destined for all-node multicast, solicited-node
multicast to BS.
3. BS delivers packets to MSs through multicast CID.
3.2. Solution CASE 1
+-----+
| MS1 |<-------------+
+-----+ v
+-----+ +-------+ +--------+
| MS2 |<---------->|BS/AR1 |<------->| Edge | ISP
+-----+ +-------+ | Router +==>Network
+--------+
+-----+ +-------+ ^
| Ms3 |<---------->|BS/AR2 |<----------+
+-----+ +-------+
Figure 5. Scenario A
o Subnet model: 1.A prefix per each MS.
o BS architecture: 1.BS/AR are in one box.
o Convergence Sublayer: Both are ok.
o Address autoconfiguration:
* Unsolicited RA from BS/AR: Use Multicast CID approach.
* DAD: DAD procedure is trivial
o Address resolution: In case of ethernet CS and IPv6 CS, the next-
hop of all MSs is BS/AR. Therefore, address resolution is
trivial.
o Conceptual sending algorithm
* Neighbor cache: In case of ethernet CS, needs only for BS/AR.
* NUD: Checks only the reachability of BS/AR.
* Next-hop determination: The next-hop of each MS is always
BS/AR.
Lee, et al. Expires August 5, 2006 [Page 12]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
3.3. Solution CASE 2
+-----+
| MS1 |<------+
+-----+ |
+-----+ | +-------+ +--------+
| MS2 |<------+--->|BS/AR1 |<------->| Edge | ISP
+-----+ +-------+ | Router +==>Network
+--------+
+-----+ +-------+ ^
| Ms3 |<---------->|BS/AR2 |<----------+
+-----+ +-------+
Figure 6. Scenario B
o Subnet model: 2.A prefix for all MSs attached to a BS/AR.
o BS architecture: 1.BS/AR are in one box.
o Convergence Sublayer: Both are ok.
o Address autoconfiguration:
* Unsolicited RA from BS/AR: Use Multicast CID approach.
* DAD: Use multicast CID approach for NS/NA message. DAD
procedure should be performed as usual.
o Address resolution: In case of ethernet CS, address resolution
should be performed as usual if MSs share a prefix with 'L' bit
set. Use multicast CID approach for NS message. In case of IPv6
CS, the next-hop of MS is always BS/AR. Therefore, address
resolution is trivial.
o Conceptual sending algorithm
* Neighbor cache: In case of ethernet CS, maintain other MS'
cache if MSs share a prefix with 'L' bit set. In case of IPv6
CS, needs only for BS/AR.
* NUD: If ethernet CS and 'L' bit set checks every entry as
usual. Otherwise, checks only the reachability of BS/AR.
* Next-hop determination: If ethernet CS and 'L' bit set next-hop
d etermination should be performed as usual. Otherwise, the
next-hop of each MS is always BS/AR.
Lee, et al. Expires August 5, 2006 [Page 13]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
3.4. Solution CASE 3
+-----+
| MS1 |<------+
+-----+ |
+-----+ | +-----+ +-----+ +--------+
| MSs |<------+----| BS1 |---->| AR |<-->| Edge | ISP
+-----+ +-----+ +-----+ | Router +==>Network
^ +--------+
+-----+ +-----+ |
| Mss |<-----------| BS2 |--------+
+-----+ +-----+
Figure 7. Scenario C
o Subnet model: 2.A prefix for all MSs attached to BSs.
o BS architecture: 2.BSs are separated from AR.
o Convergence Sublayer: In case of IPv6 CS, L2 tunnel should be used
between BS and AR.
o Address autoconfiguration:
* Unsolicited RA from AR: Use Multicast CID approach. RA should
delivered to all BSs.
* DAD: Use multicast CID approach for NS/NA message. DAD
procedure should be performed as usual.
o Address resolution: In case of ethernet CS, address resolution
should be performed as usual if MSs share a prefix with 'L' bit
set. Use multicast CID approach for NS message. In case of IPv6
CS, the next-hop of MS is always AR. Therefore, address
resolution is trivial.
o Conceptual sending algorithm
* Neighbor cache: In case of ethernet CS, maintain other MS'
cache if MSs share a prefix with 'L' bit set. In case of IPv6
CS, needs only for AR.
* NUD: If ethernet CS and 'L' bit set checks every entry as
usual. Otherwise, checks only the reachability of AR.
* Next-hop determination: If ethernet CS and 'L' bit set next-hop
determination should be performed as usual. Otherwise, the
Lee, et al. Expires August 5, 2006 [Page 14]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
next-hop of each MS is always AR.
3.5. Solution CASE 4
+-----+ +-----+ +-----+ ISP 1
| MS1 |<-----+ +->| AR1 |<-->| ER1 |===>Network
+-----+ | | +-----+ +-----+
+-----+ | +-----+ |
| MS2 |<-----+-----| BS1 |--|
+-----+ +-----+ | +-----+ +-----+ ISP 2
+->| AR2 |<-->| ER2 |===>Network
+-----+ +-----+ | +-----+ +-----+
| Ms3 |<-----------| BS2 |--+
+-----+ +-----+
Figure 8. Scenario D
o Subnet model: 2.A prefix for all MSs attached to BSs.
o BS architecture: 2.BSs are separated from ARs.
o Convergence Sublayer: In case of IPv6 CS, L2 tunnel should be used
between BS and AR.
o Address autoconfiguration:
* Unsolicited RA from AR: Use Multicast CID approach. RA should
delivered to all BSs.
* DAD: Use multicast CID approach for NS/NA message. DAD
procedure should be performed as usual.
o Address resolution: In case of ethernet CS, address resolution
should be performed as usual if MSs share a prefix with 'L' bit
set. Use multicast CID approach for NS message. In case of IPv6
CS, the next-hop of MS is always one of ARs. Therefore, address
resolution is trivial.
o Conceptual sending algorithm
* Neighbor cache: In case of ethernet CS, maintain other MS'
cache if MSs share a prefix with 'L' bit set. In case of IPv6
CS, needs only for AR.
* NUD: If ethernet CS and 'L' bit set checks every entry as
usual. Otherwise, checks only the reachability of AR.
Lee, et al. Expires August 5, 2006 [Page 15]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
* Next-hop determination: If ethernet CS and 'L' bit set next-hop
determination should be performed as usual. Otherwise, the
next-hop of each MS is always AR.
Lee, et al. Expires August 5, 2006 [Page 16]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
4. 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 August 5, 2006 [Page 17]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
5. References
5.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.
5.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-02 (work in
progress), February 2006.
[I-D.madanapalli-nd-over-802.16-problems]
Madanapalli, S., "IPv6 Neighbor Discovery over 802.16:
Problems and Goals",
draft-madanapalli-nd-over-802.16-problems-00 (work in
progress), December 2005.
[I-D.jang-16ng-llm]
"Link-local Multicast packet Transmission in 802.16
Networks", January 2006.
[I-D.shin-v6ops-deployment-scenarios]
"ISP IPv6 Deployment Scenarios in Wireless Broadband
Lee, et al. Expires August 5, 2006 [Page 18]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
Access Networks", February 2006.
Lee, et al. Expires August 5, 2006 [Page 19]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
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
Syam Madanapalli
Samsung ISO
3/1 Millers Road
Bangalore-560 052
India
Fax: +91 80 51197777
Email: syam@samsung.com
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 August 5, 2006 [Page 20]
Internet-Draft NDP over IEEE 802.16 Networks February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Expires August 5, 2006 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:25 |