Internet DRAFT - draft-xia-16ng-per-ms-prefix-nd
draft-xia-16ng-per-ms-prefix-nd
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei USA
Expires: February 26, 2007 B. Patil
Nokia
August 25, 2006
Neighbor Discovery and Address Autoconfiguration in Per-MS Subnet Prefix
Model
draft-xia-16ng-per-ms-prefix-nd-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 February 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Xia, et al. Expires February 26, 2007 [Page 1]
Internet-Draft ND and Address Autoconfiguration August 2006
Abstract
This draft defines neighbor discovery and stateless address
autoconfiguration based on IEEE 802.16d/e per-MS subnet prefix model.
In this model, an MS can have multiple IPv6 addresses, but an IPv6
prefix can only be used by one MS, that is, different MSs cannot
share the same prefix.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Virtual Link . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Virtual Link States Transitions . . . . . . . . . . . . . 6
3.1.1. Active . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Teardown . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Information Model . . . . . . . . . . . . . . . . . . . . 7
4. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Fast Router Discovery (FRD) . . . . . . . . . . . . . . . 8
4.2. Solicited Router Advertisement . . . . . . . . . . . . . . 8
4.3. Periodic Router Advertisement . . . . . . . . . . . . . . 8
5. Link Local Address Autoconfiguration . . . . . . . . . . . . . 9
5.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 9
5.2. Duplicate Address Detection . . . . . . . . . . . . . . . 9
6. Global Address Autoconfiguration . . . . . . . . . . . . . . . 10
7. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Reuse of existing standards . . . . . . . . . . . . . . . 11
7.2. On-link Multicast Support . . . . . . . . . . . . . . . . 11
7.3. Consistency in IP Link Definition . . . . . . . . . . . . 11
7.4. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 11
7.5. Effect on Dormant Mode . . . . . . . . . . . . . . . . . . 11
7.6. Changes on Host Implementation . . . . . . . . . . . . . . 11
7.7. Changes on Router Implementation . . . . . . . . . . . . . 12
7.8. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12
7.9. SeND Support . . . . . . . . . . . . . . . . . . . . . . . 12
8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Xia, et al. Expires February 26, 2007 [Page 2]
Internet-Draft ND and Address Autoconfiguration August 2006
1. Introduction
While the IEEE 802.16d/e defines the encapsulation of an IPv4/IPv6
datagram in an IEEE 802.16d/e MAC payload, a complete description of
IPv4/IPv6 operation and deployment is not present. This draft will
describe Neighbor Discovery behavior between MS and AR based on
Per-MS subnet prefix model.
Figure 1 illustrates the key elements of a typical IEEE 802.16d/e
access network.
Customer | Access Provider | Service Provider
Premise | | (Backend Network)
+-----+ +-----+ +------+ +--------+
| MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP
+-----+ +-----+ |Router| | Router +==>Network
+--+---+ +--------+
+-----+ +-----+ | | +------+
| Mss |--(802.16)--| BS |--------+ +--|AAA |
+-----+ +-----+ |Server|
+------+
Figure 1: key elements of a typical IEEE 802.16d/e access network
MSs attach BS through 802.16d/e air interface. A BS manages
connectivity of MSs and extend connections to an Access Router. An
access router is the first IP hop router for MSs.
In the shared prefix model, an IPv6 prefix is shared by multiple MSs.
[IPV6CS] defines ND behavior based on this model. There are some
cons in this model, such as,
1. complicated DAD because of lack of link-local multicast
mechanism,
2. complicated maintenance of an authoritative address cache,
especially in the scenario that address changes frequently
especially when CGA based addresses are used.
Shared subnet prefix model can be viewed as a kind of multilink
subnets model. For a more in-depth analysis of multilink subnets,
see [MULTILINK].
Per-MS subnet prefix model was first proposed for 3GPP networks in
[RECOMMENDATION]. We propose a similar per-MS subnet prefix model
for IEEE 802.16d/e network architecture in this document. That is, a
prefix is only assigned to one MS, different MSs can't share a
Xia, et al. Expires February 26, 2007 [Page 3]
Internet-Draft ND and Address Autoconfiguration August 2006
prefix, and an MS can have multiple prefixes. The later sections
will detail ND and address stateless autoconfiguration under this
model.
Xia, et al. Expires February 26, 2007 [Page 4]
Internet-Draft ND and Address Autoconfiguration August 2006
2. Terminology
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 BCP 14 [STANDARDS].
subnet: generally used to refer to a topological area that uses the
same address prefix, where that prefix is not further subdivided
except into individual addresses. In this draft, an IPv6 prefix used
stands for a subnet.
link: A communication facility or physical medium that can sustain
data communications between multiple network nodes, such as an
Ethernet. A subnet (prefix)is associated with one link. Multiple
subnets(prefixes) may be assigned to the same link. Different links
can not share the same prefix.
transport connection: An 802.16d/e based MAC connection between an MS
and a BS with specific QoS attributes. There can be multiple
connections between an MS and a BS at any given time serving
different QoS requirements of the end user applications. Each
connection is identified by an unique identifier called Connection
Identifier (CID). In the separated model where an AR and a BS are
separated physically, tunnels are established between the AR and the
BS. Tunnels can be viewed as an physical extension of a transport
connection.
virtual link: this is a logical concept above transport connections
between an MS and an AR. From IP layer perspective, there are no
differences between virtual and real links.
virtual interface: either end of a virtual link connects the link
through a virtual interface. Each interface has a 64bit identifier
which can be used for identifying the virtual link. On a given link,
an MS and an AR have independent virtual interface identifiers which
can be used for configuring a separate link local address, or a
global IP address. Each node can have more than one virtual
interface for multihoming.
Xia, et al. Expires February 26, 2007 [Page 5]
Internet-Draft ND and Address Autoconfiguration August 2006
3. Virtual Link
An MS performs initial network entry and authentication procedures as
described in 802.16d/e. Then an initial transport connection is
established between an MS and an AR. The MS or AR may create, modify
or delete transport connections dynamically. IPv6 operations run on
transport connections.
When an MS is in idle mode, all related transport connections are
destroyed. The MS keeps the IPv6 address unchanged.
When an MS switches off or hands off, all the connections are
destroyed. The prefixes assigned should be released.
A virtual link is a logical concept which consists of one or more
transport connections. An MS can have one or more virtual links to
an AR. Each virtual link has one or more prefixes, while each prefix
can only be used in one virtual link.
3.1. Virtual Link States Transitions
3.1.1. Active
When an initial transport connection is created, a virtual link is
also created at the same time and the state is active. In this
state, transport connections can be added, modified, and deleted to
this link. From IP layer perspective, the virtual link is not any
different from such links as Ethernet, PPP. ND can run on a virtual
link in active state without any modifications.
3.1.2. Shutdown
When an MS becomes dormant, all connections are destroyed, and
related virtual link's state becomes shutdown. In this state, the MS
holds it's IPv6 address, and the link attributes such as prefixes
keep unchanged, but there are no ND signaling exchanges between the
MS and the AR. When the MS initiates a session or receives an
incoming session, one or more transport connections are added to the
virtual link, and the state transits to an active one.
3.1.3. Teardown
When an MS switches off or is handed over, a virtual link is torn
down, and all the transport connections are destroyed. Prefixes
assigned to the virtual link SHOULD be released.
Xia, et al. Expires February 26, 2007 [Page 6]
Internet-Draft ND and Address Autoconfiguration August 2006
3.2. Information Model
Neighbor discovery protocol runs on a virtual link. When an MS
receives NS/NA/RA or an AR receives NS/NA/RS from a CID, these nodes
will map the CID to a related virtual link for further process. When
an MS sends NS/NA/RS or an AR sends NS/NA/RA to a virtual link, these
nodes will map the virtual link to a related CID for transport.
Each MS and AR have a virtual link information table which include
following elements:
1. virtual interface identifier which can be used to identify the
virtual link. For the same virtual link, an AR and an MS create
their virtual interfaces independently. In the same node,
different interfaces MUST have different identifiers.
2. prefixes which are assigned to the link for address
autoconfiguration.
3. CIDs which compose the virtual link.
4. optional items such as MTU and so on.
When an MS hands over to another BS under the same AR, the MS and the
AR deletes the existing CIDs and adds one or more new CIDs. Other
attributes of this entry including prefixes are kept unchanged.
When an MS becomes dormant, the MS and AR deletes all existing CIDs.
When the MS becomes active again, new CIDs are created and added to
the entry.
Xia, et al. Expires February 26, 2007 [Page 7]
Internet-Draft ND and Address Autoconfiguration August 2006
4. Prefix Assignment
When an MS attaches to an AR, prefixes SHOULD be assigned to the MS.
When the MS detaches from the AR, prefixes SHOULD be reclaimed. The
AR can manage prefixes through DHCPv6. That is, when the AR needs to
assign prefixes to an MS, it requests these prefixes from a DHCP
server, and when the MS detaches the AR, the AR gives back the
prefixes to the DHCP server. There are also some alternatives to
manage prefixes. In this memo, how an AR assigns prefixes to an MS
is our topic.
4.1. Fast Router Discovery (FRD)
As soon as a virtual link becomes active, an AR sends a suitable
unsolicited RA. In this message, one or more prefixes are included.
4.2. Solicited Router Advertisement
When a virtual link is active, an MS sends an RS with all-routers
multicast address as destination address and unspecified address as
source address on the link. The AR responds with a suitable RA with
all-nodes multicast address as the destination IP address and the AR
link local address as the source address.
4.3. Periodic Router Advertisement
When a virtual link is active, periodic router advertisement SHOULD
be performed as per [DISCOVERY]. When an MS is in idle mode, the
corresponding virtual link is in shutdown state, and an AR never
advertises an RA message on a shutdown link. Thus an MS never wakes
up just because of receiving a RA. The MaxRtrAdvInterval should be
configurable to quite a high value to relieve RA traffic through air
interface.
Xia, et al. Expires February 26, 2007 [Page 8]
Internet-Draft ND and Address Autoconfiguration August 2006
5. Link Local Address Autoconfiguration
5.1. Interface Identifier
An MS can generate it's interface identifier from its MAC address as
per [ARCHI]. The MS may also generate random interface identifiers
as per [PESAA]. An AR generates an identifier for a virtual
interface as it does for a physical one.
5.2. Duplicate Address Detection
When a virtual link is created, an MS and an AR create their
respective link local addresses and do DAD within the link
independently.
Xia, et al. Expires February 26, 2007 [Page 9]
Internet-Draft ND and Address Autoconfiguration August 2006
6. Global Address Autoconfiguration
An AR advertises the prefixes by putting PIO (Prefix Information
Option) in the Router Advertisements and an MS learns the prefix
information by consulting these PIOs. The MS and the AR concatenate
prefix and interface ID to create their own global addresses
independently. DAD is done within the virtual link scope.
Xia, et al. Expires February 26, 2007 [Page 10]
Internet-Draft ND and Address Autoconfiguration August 2006
7. Considerations
7.1. Reuse of existing standards
In this model, almost all the work is focused on how to maintain a
virtual link. From IP layer perspective, there is no difference
between a real link and a virtual one. So, ND protocol can run on a
virtual link without any modification and limitation.
7.2. On-link Multicast Support
Only an MS and an AR connect to a virtual link. On-link multicast is
supported, but the scope is limited. On-link multicast is the same
as unicast.
7.3. Consistency in IP Link Definition
In [MULTILINK], there is IP Link definition and explanation. The
main idea is that a subnet is considered to be a subset of a link.
That is, a link can have one or more subnets, but one subnet can only
span one link.
In per-MS subnet prefix model, a prefix can be viewed as a subnet. A
virtual link can be assigned to one or more prefixes, while one
prefix can only be used by one link. This model is consistent with
original IP model.
7.4. Packet Forwarding
From a data plane perspective, an AR behavior is almost the same as a
router. The difference is that a router has limited static physical
interfaces while an AR has many dynamic virtual interfaces. The AR
broadcasts prefix route information to the Internet. An aggregated
route can be used to avoid route flips.
7.5. Effect on Dormant Mode
Link-local multicast is limited in a virtual link. An MS is waken up
only when there is some traffic. Thus, battery can be used
efficiently.
7.6. Changes on Host Implementation
Virtual links MUST be maintained to provide a consistent interface to
the IP layer. Any function modules above the link layer can be used
without any modification. As there is very low address duplication
possibility, Optimistic DAD as per [OPTDAD] is preferable.
Xia, et al. Expires February 26, 2007 [Page 11]
Internet-Draft ND and Address Autoconfiguration August 2006
7.7. Changes on Router Implementation
Following functions should be added in an AR
1. virtual link management: to create and destroy links, and to
maintain links' states.
2. prefix management: to allocate and reclaim prefixes for MSs
3. route management: to broadcast MSs route information dynamically.
Prefix management can be considered with route management at the same
time. For example, each AR can be assigned a /48 prefix, while an
MS' /64 prefix is derived from the /48 prefix extension.
7.8. Renumbering
Each prefix has it's lifetime, and multiple prefixes can be assigned
to a virtual link at the same time. Renumbering function can be
obtained. For example, if a carrier wants to change it's /48 prefix,
all corresponding /64 prefixes MUST be advertised to MSs. Compared
to the shared subnet prefix model, per-MS subnet prefix has more
signaling traffic while renumbering.
7.9. SeND Support
An MS can generate an virtual interface identifier of an IPv6 address
by computing a cryptographic hash of the public key.
SeND is supported.
Xia, et al. Expires February 26, 2007 [Page 12]
Internet-Draft ND and Address Autoconfiguration August 2006
8. Applicability
This model is applicable for both IPv6 CS and Ethernet CS. It can be
used not only Integrated AR-BS model (Profile B in WiMAX
architecture) but also separated AR-BS one (Profiles A and C).
Xia, et al. Expires February 26, 2007 [Page 13]
Internet-Draft ND and Address Autoconfiguration August 2006
9. Security Considerations
There are existing security concerns with Neighbor Discovery and
Stateless Address Auto configuration. Secure Neighbor Discovery
(SEND) [SEND] provides protection against the threats to Neighbor
Discovery described in [NDTM]. This memo does not introduce any
additional threats to Neighbor Discovery, and SEND can be used.
Xia, et al. Expires February 26, 2007 [Page 14]
Internet-Draft ND and Address Autoconfiguration August 2006
10. References
10.1. Normative References
[ADDRCONF]
Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2462>.
[ARCHI] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4921, February 2006,
<ftp://ftp.isi.edu/in-notes/rfc4291>.
[DISCOVERY]
Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999,
<ftp://ftp.isi.edu/in-notes/rfc2710>.
[NDTM] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004, <ftp://ftp.isi.edu/in-notes/rfc3756 >.
[OPTDAD] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006,
<ftp://ftp.isi.edu/in-notes/rfc4429>.
[PESAA] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.
[RECOMMENDATION]
Wasserman, Ed., M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002,
<ftp://ftp.isi.edu/in-notes/rfc3314>.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
Neighbor Discovery (SEND)", RFC 3971, March 2005,
<ftp://ftp.isi.edu/in-notes/rfc3971>.
[STANDARDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119>.
Xia, et al. Expires February 26, 2007 [Page 15]
Internet-Draft ND and Address Autoconfiguration August 2006
10.2. Informative References
[IPV6CS] Madanapalli, S., Patil, B., Nordmark, E., Choi, J., and
S. Park, "Transmission of IPv6 over 802.16's IPv6
Convergence Sublayer", June 2006, <http://www.ietf.org/
internet-drafts/
draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt>.
[MULTIENCAP]
Aboba,Ed., B., Davies, Elwyn., and Dave. Thaler,
"Multiple Encapsulation Methods Considered Harmful",
July 2006, <http://www.ietf.org/internet-drafts/
draft-iab-link-encaps-02.txt>.
[MULTILINK]
Thaler, Dave., "Issues With Protocols Proposing Multilink
Subnets", February 2006, <http://www.ietf.org/
internet-drafts/
draft-thaler-intarea-multilink-subnet-issues-00.txt>.
Xia, et al. Expires February 26, 2007 [Page 16]
Internet-Draft ND and Address Autoconfiguration August 2006
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Email: sarikaya@ieee.org
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
Phone:
Email: basavaraj.patil@nokia.com
Xia, et al. Expires February 26, 2007 [Page 17]
Internet-Draft ND and Address Autoconfiguration August 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).
Xia, et al. Expires February 26, 2007 [Page 18]
