16ng Working Group S. Madanapalli, Ed.
Internet-Draft LogicaCMG
Intended status: Informational September 26, 2006
Expires: March 30, 2007
Analysis of IPv6 Link Models for 802.16 based Networks
draft-madanapalli-16ng-subnet-model-analysis-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 30, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides different IPv6 link models that are suitable
for 802.16 based networks and provides analysis of various
considerations for each link model and the applicability of each link
model under different deployment scenarios. This document is result
of a Design Team that was formed to analyze the IPv6 link models for
802.16 based networks.
Madanapalli Expires March 30, 2007 [Page 1]
Internet-Draft IPv6 Link Models for 802.16 September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Link Models for 802.16 based Networks . . . . . . . . . . 4
3.1. Shared IPv6 Prefix Link Model . . . . . . . . . . . . . . 4
3.1.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 5
3.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 5
3.1.3. Duplicate Address Detection . . . . . . . . . . . . . 5
3.1.4. Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Applicability . . . . . . . . . . . . . . . . . . . . 7
3.2. Point-to-point Link Model . . . . . . . . . . . . . . . . 7
3.2.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 8
3.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 8
3.2.3. Considerations . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Applicability . . . . . . . . . . . . . . . . . . . . 10
3.3. Ethernet Like Link Model . . . . . . . . . . . . . . . . . 10
3.3.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 11
3.3.2. Address Autoconfiguration . . . . . . . . . . . . . . 11
3.3.3. Duplicate Address Detection . . . . . . . . . . . . . 11
3.3.4. Considerations . . . . . . . . . . . . . . . . . . . . 11
3.3.5. Applicability . . . . . . . . . . . . . . . . . . . . 12
4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Effect on Dormant Mode . . . . . . . . . . . . . . . . . . . . 13
6. SeND Support . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Conclusions and Relevant Link Models . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Madanapalli Expires March 30, 2007 [Page 2]
Internet-Draft IPv6 Link Models for 802.16 September 2006
1. Introduction
802.16 [1] [2] is a connection oriented access technology for the
last mile without bi-directional native multicast support. 802.16 has
only downlink multicast support and there is no mechanisms defined
for MSs to be able to send multicast packets that can be mapped to
downlink multicast connection. This could be a problem for IP
protocols (e.g. ARP, IPv6 ND) that traditionally assume the
availability of multicast at the link layer. This is further
complicated by the definition of commercial network models like
WiMAX, which defines the Service Flows that extends the 802.16b MAC
transport connection all the way to an Access Router by using a
tunnel between BS and AR. This leads to multiple ways of deploying
IP over 802.16 based networks.
This document looks at various considerations in selecting a link
model for 802.16 based networks and provides analysis of the various
possible link models.
2. Terminology
Access Router: An entity, which performs IP routing function to
provide IP connectivity for MSs. In WiMAX Networks, the AR is an ASN
Gateway.
Base Station (BS): A generalized equipment sets providing
connectivity, management, and control of the subscriber station (SS).
Dormant Mode: A state in which a mobile station restricts its ability
to receive normal IP traffic by reducing monitoring of radio
channels. This allows the mobile station to save power and reduces
signaling load on the network. In the dormant mode, the MS is only
listening at scheduled intervals to the paging channel. The network
maintains state about an MS which has transitioned to dormant mode
and can page it when needed.
IP Link: This has been defined in [3] as below.
- a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernets (simple or bridged), PPP links, X.25,
Frame Relay, or ATM networks as well as Internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
Mobile Station: An end-user equipment that provides connectivity to
802.16 based networks.
Point-to-multipoint: A link consists of a single interface
Madanapalli Expires March 30, 2007 [Page 3]
Internet-Draft IPv6 Link Models for 802.16 September 2006
communicating directly with more than one interface.
3. IPv6 Link Models for 802.16 based Networks
This section provides various IPv6 link models for 802.16 based
networks and provides their operational considerations in practical
deployment scenarios.
3.1. Shared IPv6 Prefix Link Model
The following figures illustrates high level view of the link model
using shared prefix for IPv6 link wherein one more prefixes
advertised on the link would be used by the all nodes attached to the
IPv6 link.
+-----+
| MS1 |-----+
+-----+ |
|
|
+-----+ | +-----+ +--------+
| MS2 |-----+-----| BS1 |----------| AR |-------[Internet]
+-----+ | +-----+ +--------+
. | ____________
. | ()__________()
+-----+ | L2 Tunnel
| MSn |-----+
+-----+
Figure 1. Shared IPv6 Prefix Link Model
The above figure shows the case where BS and AR exist as separate
entities, in this case a tunnelled interface exists between the BS
and AR per MS basis.
In this link model, the link between the MS and the AR at the IPv6
layer is viewed as a shared link and the lower layer link between the
MS and BS is a point-to-point link. This point-to-point link between
the MS and BS is extended all the way to the AR when the granularity
of the tunnel between the BS and AR is on per MS basis. This is
illustrated in the following figure below.
Madanapalli Expires March 30, 2007 [Page 4]
Internet-Draft IPv6 Link Models for 802.16 September 2006
MS
+----+ +----+
| | IPv6 (Shared link) | |
| L3 |=====================================| |
| | | |
|----| PTP conn. +----+ L2 Tunnel | AR |---[Internet]
| L2 |-------------| BS |==================| |
| | | | | |
+----+ +----+ | |
| |
+----+ L2 Tunnel | |
| BS |==================| |
| | | |
+----+ +----+
Figure 2. Shared IPv6 Prefix Link Model - Layered View
In this link model, an AR can serve one or more BSs. All MSs
connected to BSs that are served by an AR are on the same IPv6 link.
This model is different from Ethernet Like Link model wherein the
later model provides Ethernet link abstraction and multicast
capability to IPv6 layer.
3.1.1. Prefix Assignment
One or more IPv6 prefixes are assigned to the link and hence shared
by all the nodes that are attached to the link. The prefixes are
advertised with autonomous flag (A-Flag) set and the On-link flag
(L-flag) reset for address autoconfiguration so that the nodes may
not make an on-link assumption for the addresses in those prefixes.
3.1.2. Address Autoconfiguration
There is no change to normal IPv6 address autoconfiguration
mechanisms, which are specified in [4] [6].
3.1.3. Duplicate Address Detection
The DAD procedure as specified in [4] does not adapt well to the
802.16 air interface as there is no native multicast support and when
supported consumes air bandwidth as well as it would have adverse
effect on MSs that were in the dormant mode. An optimization, called
Relay DAD, may be required to perform DAD. In Relay DAD the MS
behavior is same as specified in [4] and the optimization is achieved
with the network support. For this, the AR should maintain the list
Madanapalli Expires March 30, 2007 [Page 5]
Internet-Draft IPv6 Link Models for 802.16 September 2006
of addresses, called Address Cache, that are currently in use within
the IP link. The relay DAD works as below:
1. An MS constructs a Link Local Address as specified in [4].
2. The MS constructs a solicited node multicast address for the
corresponding Link Local Address and sends MLD Join request for
the solicited node multicast address.
3. The MS starts verifying address uniqueness by sending a DAD NS on
the initial MAC transport connection.
4. The AR looks into the address cache to check if the address is
already in use.
5. The AR relays the DAD NS to the address owner in case there is a
match in the address cache. The address owner defends the
address by sending DAD NA, which is relayed to the DAD
originating MS via the AR.
6. Upon on receiving the DAD NA, the MS discards the tentative
address and behaves as specified in [4].
3.1.4. Considerations
3.1.4.1. Reuse of existing standards
The shared IPv6 prefix model uses the existing specification and does
not require any protocol changes or any new protocols. However this
model requires implementation changes for DAD optimization on the AR.
3.1.4.2. On-link Multicast Support
No native on-link multicast is possible with this method. However
the AR can implement proxy mechanism for the on-link multicast if
required on case-to-case basis.
3.1.4.3. Consistency in IP Link Definition
The definition of IPv6 link is consistent for all procedures and
functionalities except for the support of native on-link multicast
support. However this can be supported with AR proxying for the
multicast packets, which may increase the complexity of the AR
implementation.
3.1.4.4. Packet Forwarding
This model requires that all MSs send the packets to the AR
irrespective of the destination and scope of the IPv6 address. The
AR handles the packets with external IPv6 addresses normally.
However the packets with link local destination addresses are relayed
by the AR to destination without decrementing the hop-limit.
Madanapalli Expires March 30, 2007 [Page 6]
Internet-Draft IPv6 Link Models for 802.16 September 2006
3.1.4.5. Changes on Host Implementation
This link model does not require any implementation changes on the
host side. However the hosts are required to perform duplicate
address detection for all addresses even if the host is reusing the
interface identifier.
3.1.4.6. Changes on Router Implementation
This link model requires implementation changes on the AR for
supporting Relay DAD. Relay DAD requires the maintenance of an
Address Cache containing a list of addresses that are in use on a
particular link. The address cache may not be complete all the time
due to loss of DAD probes or hosts not performing DAD when reusing
the IID. There can also be possible DoS attack from the hosts by
configuring more number of addresses to overflow the address cache
which requires the operator to limit the number of IPv6 address a
host can have at any given instance.
3.1.5. Applicability
This model is applicable to service provider public access networks
like cellular networks in conjunction with IPv6 CS. This model can
also be used in scenarios where the support for on-link multicast is
required for service discovery; in this scenario the AR is expected
to implement proxy support for multicast packets.
This link model is also under consideration of the WiMAX Forum
Network Working Group for using with IPv6 CS access.
3.2. Point-to-point Link Model
In WiMAX, there exists a point-to-point connection between an MS and
the AR, which acts as the first hop router, bridged through a BS,
over which packets are transferred. In this model, a set of
connections between an MS and the AR are treated as a single link.
The point-to-point link model follows the recommendations of [8]. In
this model, each link between the MS and the AR is allocated a
separate, unique prefix or a set of unique prefixes by the AR. No
other node under the AR has the same prefixes on the link between it
and the AR. The following diagram illustrates this model.
Madanapalli Expires March 30, 2007 [Page 7]
Internet-Draft IPv6 Link Models for 802.16 September 2006
+----+ +----+
+-----+ | | Tunnel | |
| MS1 |-------------|....|===================| |
+-----+ | | | |
| | | |
+-----+ | | Tunnel | |
| MS2 |-------------|....|===================| |---[Internet]
+-----+ | | | AR |
| BS | | |
+-----+ | | Tunnel | |
| MS3 |-------------|....|===================| |
+-----+ | | | |
+----+ +----+
Figure 3. Point-to-point Link Model
There are multiple possible ways that the point-to-point link between
the AR and the MS can be implemented.
1. One way to accomplish this is to run PPP on the link [8].
Running PPP requires that the 802.16 link use the Ethernet CS and
PPP over Ethernet [10]. Since the IPv6 CS does not support PP,
whether PPP can be run depends on the network architecture.
2. If the actual physical medium is shared, like Ethernet, but PPP
is not run, the link can be made point to point between the MS
and AR by having each MS on a separate VLAN [12].
3. If neither PPP nor VLAN is used, the set of 802.16 connections
can be viewed as a virtual point-to-point link for the purpose of
neighbor discovery and address configuration. For IPv6 CS, this
may be used to implement the point-to-point link.
3.2.1. Prefix Assignment
Prefixes are assigned to the link using the standard [3] Router
Advertisement mechanism. The AR assigns a unique prefix or set of
unique prefixes for each MS. In the prefix information options, both
the A-flag and L-flag are set to 1, as they can be used for address
autoconfiguration and the prefixes are on link.
3.2.2. Address Autoconfiguration
MSs perform link local as well as global address autoconfiguration
exactly as specified in [4], including duplicate address detection.
Because there is only one other node on the link, the AR, there is
only a possibility of an address conflict with the AR, so collisions
are statistically very unlikely, and easy to fix if they should
Madanapalli Expires March 30, 2007 [Page 8]
Internet-Draft IPv6 Link Models for 802.16 September 2006
occur.
If DHCP is used for address configuration ('M=1' in the Router
Advertisement), the DHCP server must provide addresses with a
separate prefix per MS. The prefix must of course match whatever
prefix the ASN Gateway has advertised to the MS (if any).
3.2.3. Considerations
3.2.3.1. Reuse of existing standards
This solution reuses RFC 2461, 2462, and if PPP is used, RFC 2472 and
RFC 2516. No changes in these protocols are required, the protocols
must only be configured properly.
If PPP is not used, any VLAN solution, such as IEEE 802.1Q [9], or
any L2 tunnel can be used.
3.2.3.2. On-link Multicast Support
Since the link between the MS and the AR is point to point, any
multicast can only be sent by one or the other node. Link local
multicast between other nodes and the AR will not be seen.
3.2.3.3. Consistency in IP Link Definition
The IP link is fully consistent with a standard IP point-to-point
link, without exception.
3.2.3.4. Packet Forwarding
The MS always sends all packets to the AR, because it is the only
other node on the link. Link local unicast and multicast packets are
also forwarded only between the two.
When the p2p link model is used, the BS acts as a bridge. For each
MS, the BS bridges the unique prefix or set of prefixes assigned by
the AR to the link between itself and the MS. This means, in
particular, that the per MS prefix or set of prefixes are routed on
both sides (wireless and wired) of the BS, and that the BS needs to
participate in all 802 standard bridging protocols.
3.2.3.5. Changes on Host Implementation
Host implementations follow standard IPv6 stack procedures. No
changes needed.
Madanapalli Expires March 30, 2007 [Page 9]
Internet-Draft IPv6 Link Models for 802.16 September 2006
3.2.3.6. Changes on Router Implementation
If PPP is used, no changes in router implementations are needed. If
PPP is not used, the AR must be capable of doing the following:
1. Each MS is assigned a separate VLAN when 802.1X [13] or each MS
must have an L2 tunnel to the AR to aggregate all the connections
to the MS and present these set of connections as an interface to
the IPv6 layer.
2. The AR must be configured to include a unique prefix or set of
prefixes for each MS. This unique prefix or set of prefixes must
be included in Router Advertisements every time they are sent,
and if DHCP is used, the addresses leased to the MS must include
only the uniquely advertised prefixes.
Note that, depending on the router implementation, these functions
may or may not be possible with simple configuration. No protocol
changes are required, however.
3.2.4. Applicability
In enterprise networks, shared services including printers, fax
machines, and other such on-line services are often available in on
the local link. These services are typically discovered using some
kind of link local service discovery protocol. The unique prefix per
MS model is not appropriate for these kinds of deployments, since it
is not possible to have shared link services in the ASN.
The p2p link model is applicable to deployments where there are no
shared services in the ASN. Such deployments are typical of service
provider networks where a public access wireless network is being
provided. Cellular networks such as UMTS networks are an example.
3.3. Ethernet Like Link Model
This model describes a scheme for configuration and provisioning of
an IEEE 802.16 networks so that it emulates a broadcast link in a
manner similar to Ethernet. Figure 4 illustrates an example of the
Ethernet model. This model essentially functions like an Ethernet
link, which means the model works as described in [3], [4].
One way to construct an Ethernet like link is to implement bridging
between BSs and AR like switched Ethernet. In the Figure 4, bridging
performs link aggregation between BSs and AR. Bridging also supports
multcast packet filtering. Another way to implement this model is by
using VLAN function [12].
In this model, an IPv6 prefix is shared by multiple MSs on top of
IEEE 802.16 point-to-multipoint links. Also this model supports
Madanapalli Expires March 30, 2007 [Page 10]
Internet-Draft IPv6 Link Models for 802.16 September 2006
multiple access routers and multiple hosts behind an MS as shown in
Figure 4.
+-----+ +---+ +----+ +-----+ ISP 1
| MS1 |-+ | | +---|AR1 |---| ER1 |===>Network
+-----+ | | S| | +----+ +-----+
+-----+ | +-----+ |E w| |
| MS2 |-+--| BS1 |--|t i| |
+-----+ +-----+ |h t|--+
| c| | +----+ +-----+ ISP 2
+-----+ +-----+ +-----+ | h| +---|AR2 |---| ER2 |===>Network
|Hosts|--|MS/GW|----| BS2 |--| | +----+ +-----+
+-----+ +-----+ +-----+ +---+
A network
may exists behind
MS/GW
Figure 4: Ethernet Like Link Model
3.3.1. Prefix Assignment
Prefixes are assigned as specified in [3], [4].
3.3.2. Address Autoconfiguration
It is the same as described in [4].
3.3.3. Duplicate Address Detection
It is the same as described in [4].
If the full Ethernet broadcast/multicast functions are not supported,
the DAD procedure as specified in [4] does not adapt well. In such
case Relay DAD mechanism can be used.
3.3.4. Considerations
3.3.4.1. Reuse of existing standards
All the IPv6 standards can be preserved or reused, but the scope is
limited or some implementation changes for DAD or on-link multicast
optimization may be required, if the full Ethernet broadcast/
Madanapalli Expires March 30, 2007 [Page 11]
Internet-Draft IPv6 Link Models for 802.16 September 2006
multicast functions are not supported.
3.3.4.2. On-link Multicast Support
On-link multicast can be emulated in unicast manner by efficiently
bridging between all BSs with IEEE 802.16 providing the links between
the MSs and the bridge on top of the BS. Nevertheless, in case of
bridging, direct inter-MSs communication may not be not allowed due
to restrictions from the service providers. Another way to emulate
on-link multicast is to use VLAN.
3.3.4.3. Consistency in IP Link Definition
This model is consistent with IP link definition.
3.3.4.4. Packet Forwarding
When properly configured and assisted by a simple bridging or VLAN
functions, IEEE 802.16 can emulate a simple broadcast network like
Ethernet.
3.3.4.5. Changes on Host Implementation
No special impact on host implementation.
3.3.4.6. Changes on Router Implementation
No special impact on router implementation under a separated AR-BS
model, if the bridging is implemented in BS. Some networks e.g.
WiMAX networks may require bridging or VLAN to be implemented in the
AR (ASN Gateway).
3.3.5. Applicability
This model works with the Ethernet CS and is chosen by the WiMAX
networks (e.g. fixed/nomadic deployment) by the WiMAX Forum Network
Working Group.
4. Renumbering
If the downstream prefixes managed by the AR are involved in
renumbering, it may be necessary to renumber each link under the AR.
The point-to-point link model requires that each MN change its
prefix, whereas the Shared IPv6 prefix and Ethernet Like Link models
require changing prefixes of the link. [11] discusses recommended
procedures for renumbering.
Madanapalli Expires March 30, 2007 [Page 12]
Internet-Draft IPv6 Link Models for 802.16 September 2006
If address autoconfiguration is used, the AR must withdraw the
existing prefixes and advertise the new ones. Since each MS
irrespective of the Link Model is on a separate point-to-point link
at the MAC level because of the 802.16 connection oriented
architecture, AR/BS send an RA withdrawing the old prefix and
advertising the new to each MS. However the Ethernet like link
model, the AR may send single RA to BS, which would be sending
separate RAs to each MS. If the Shared IPv6 link model and Ethernet
like Link model uses the downlink multicast capability, a single RA
would be sufficient to renumber the link.
If DHCP is used to assign addresses, either the DHCP address lease
lifetime may be reduced prior to the renumbering event to encourage
MSs to renew their addresses quickly or a DHCP Reconfigure message
may be sent to each of the MSs by the server to cause them to renew
their addresses. In either case, the number of messages sent is same
for all link models. After MSs have changed their addresses, the
amount of DAD traffic is same for all types of link models.
5. Effect on Dormant Mode
If the network needs to deliver packets to an MS which is in dormant
mode, the network pages the MS. The MS which is monitoring the
paging channel receives the page and transitions out of the dormant
mode to active mode. It establishes connectivity with the network by
requesting and obtaining the radio resources. The network is then
able to deliver the packets to the MS. In many networks, packets
destined to an MS in dormant mode are buffered at an entity in the
network until connectivity is established.
Support for dormant MSs is critical in mobile networks and hence it
is a necessary feature. Paging capability and optimizations possible
for paging an MS are not either enhanced or handicapped by the link
model itself. However the multicast capability of within a link may
cause for an MS to wake up for unwanted packet, this can be avoided
by filtering the multicast packets and delivering the packets to only
for MSs that are listening for particular multicast packets. As the
Shared IPv6 Prefix model does not have the multicast capability and
point-to-point link model has only one node on the link, they do not
have any effect on the dormant mode. The Ethernet like link model
may have the multicast capability, which requires filtering at the BS
to support the dormant mode for the MSs.
6. SeND Support
SEND is fully supported by all models described in this document.
Madanapalli Expires March 30, 2007 [Page 13]
Internet-Draft IPv6 Link Models for 802.16 September 2006
And SeND should be used to secure the neighbor discovery procedures.
7. Conclusions and Relevant Link Models
Ethernet Like Link model would be used when the deployment requires
the use of Ethernet CS as this is the only model being proposed for
the Ethernet CS and running IPv6 over Ethernet is well understood.
For IPv6 CS, point-to-point link model appears to the choice because
of its simplicity for performing the DAD as well as the operational
experience of p2p links from 3G networks. However the IPv6 shared
prefix model would be defined if there is any interest from service
provider community.
8. Security Considerations
This document provides the analysis of various IPv6 link models for
802.16 based networks and this document as such does not introduce
any new security threats. Nonetheless, this document encourages
usage of SeND for securing the neighbor discovery messages on any
IPv6 link. Also the Relay DAD procedure, which requires the
maintenance of address cache, may be attacked from rogue users by
forming large number of IPv6 addresses to overflow the address cache,
this may require service providers to limit the number of IPv6
address for a user at a given instance.
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgements
This document is a result of discussions in v6subnet design team for
IPv6 Prefix Model Analysis. The members of this design team in
alphabetical order were: Dave Thaler, David Johnston, Junghoon Jee,
Max Riegel, Myungki Shin and Syam Madanapalli. The discussion in the
DT was benefited from the active participation of James Kemp, Behcet
Sarikaya, Basavaraj Patil and JinHyeock Choi in the DT mailing list.
The DT thanks the chairs (Gabriel Montenegro Soohong Daniel Park) and
Shepherding AD (Jari Arkko) for their active participation and
motivation.
Madanapalli Expires March 30, 2007 [Page 14]
Internet-Draft IPv6 Link Models for 802.16 September 2006
11. Contributors
The members who provided the text based on the DT discussion are:
Myung-Ki Shin
ETRI
myungki.shin@gmail.com
James Kempf
DoCoMo Communications Labs USA
kempf@docomolabs-usa.com
Soohong Daniel Park
Samsung Electronics
soohong.park@samsung.com
JinHyeock Choi
Samsung Advanced Institute of Technology
jinchoe@samsung.com
Behcet Sarikaya
Huawei USA
sarikaya@ieee.org
12. References
[1] "IEEE 802.16-2004, IEEE standard for Local and metropolitan
area networks, Part 16:Air Interface for fixed broadband
wireless access systems", October 2004.
[2] "IEEE 802.16e, IEEE standard for Local and metropolitan area
networks, Part 16:Air Interface for fixed and Mobile broadband
wireless access systems", October 2005.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Madanapalli Expires March 30, 2007 [Page 15]
Internet-Draft IPv6 Link Models for 802.16 September 2006
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[8] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314,
September 2002.
[9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[10] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[11] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[12] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q",
May 2003.
[13] "IEEE, Port-based Network Access Control, IEEE 802.1X",
December 2004.
Author's Address
Syam Madanapalli (editor)
LogicaCMG
125 Yemlur P.O.
Off Airport Road
Bangalore 560037
India
Email: smadanapalli@gmail.com
Madanapalli Expires March 30, 2007 [Page 16]
Internet-Draft IPv6 Link Models for 802.16 September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Madanapalli Expires March 30, 2007 [Page 17]