One document matched: draft-sarikaya-16ng-prefix-delegation-01.txt
Differences from draft-sarikaya-16ng-prefix-delegation-00.txt
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei USA
Expires: September 5, 2007 March 4, 2007
Using DHCPv6 and AAA Server for Mobile Station Prefix Delegation
<draft-sarikaya-16ng-prefix-delegation-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 September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires September 5, 2007 [Page 1]
Internet-Draft Prefix Delegation March 2007
Abstract
In the 802.16 Per-MS prefix model, one prefix can only be assigned to
one mobile station by an access router and different mobile stations
can't share a prefix. Managing Per-MS prefixes is likely to increase
the processing load at the access router. Based on the idea that
DHCPv6 servers can manage prefixes as well as addresses, we propose a
new technique in which the access router offloads delegation and
release tasks of the prefixes to an DHCPv6 server. The access router
first requests a prefix for an incoming mobile station to the DHCPv6
server. The access router next advertises the prefix information to
the mobile station with a Router Advertisement message. When the
mobile station leaves, the prefix is returned to the DHCPv6 server.
We also describe how prefix delegation can be done by AAA servers as
an alternative technique.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . . . . 4
3.1. Prefix Request Procedure for Stateless Address
Configuration . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Prefix Request Procedure for Stateful Address
Configuration . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Prefix Release Procedure . . . . . . . . . . . . . . . . . 6
3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.1. Renumbering Through Renew Message . . . . . . . . . . 6
3.4.2. Server Initiated Reconfiguration . . . . . . . . . . . 7
3.5. Miscellaneous Considerations . . . . . . . . . . . . . . . 7
3.5.1. Triggers for an AR to initiate prefix request
procedure . . . . . . . . . . . . . . . . . . . . . . 7
3.5.2. How to generate IAID . . . . . . . . . . . . . . . . . 7
3.5.3. Policy to delegate prefixes . . . . . . . . . . . . . 7
4. Prefix Delegation Using RADIUS and Diameter . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Xia & Sarikaya Expires September 5, 2007 [Page 2]
Internet-Draft Prefix Delegation March 2007
1. Introduction
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
Mobile stations (MS) attach to a base station (BS) through 802.16d/e
air interface. A BS manages connectivity of MSs and extend
connections to an Access Router (AR). The Access router is the first
IP hop router of MSs.
As to IPv6 addressing, there are two models, shared prefix and Per-MS
prefix. In the shared prefix model, an IPv6 prefix is shared by
multiple MSs. While in the Per-MS prefix model, a prefix is only
assigned to one MS. Different MSs can't share a prefix, and an MS
can have multiple prefixes.
[I-D.ietf-16ng-ipv6-link-model-analysis] briefly compares the two
models. Per-MS model has some advantages, such as, no complicated
duplicate address detection (DAD), fit naturally to the point-to-
point links and so on. In Per-MS prefix model, prefix management is
an issue.
When an MS attaches an AR, the AR requests one or more prefixes for
the MS. When the MS detaches the AR, the prefixes should be
released. When the MS becomes idle, the AR should hold the prefixes
allocated. When an operator wants to renumber its network, prefixes
with different lifetime are advertised to the MS.
DHCPv6 is a preferable way to manage the prefixes. At the same time,
AAA protocols, RADIUS and Diameter, are also alternatives for prefix
delegation.
Xia & Sarikaya Expires September 5, 2007 [Page 3]
Internet-Draft Prefix Delegation March 2007
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 [RFC2119].
This document uses the terminology defined in [RFC3315], [RFC3633]
and [I-D.ietf-16ng-ps-goals].
3. Prefix Delegation Using DHCPv6
3.1. Prefix Request Procedure for Stateless Address Configuration
+-------+ +-------+ +-----------+
| MS | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 N/W Entry & Auth | |
|<--------------------->| |
| |2 Relay-forward/Solicit|
| |---------------------> |
| | |
| |3 Relay-reply/Advertise|
| |<--------------------- |
| | |
| |4 Relay-forward/Request|
| |---------------------> |
| | |
| |5 Relay-reply/Reply |
| |<--------------------- |
|6 Transport Connection | |
| Established | |
|<--------------------->| |
| | |
| 7 Router Advertisement| |
|---------------------->| |
| | |
| 8 MLD Join | |
|---------------------->| |
| | |
| 9 DAD Procedure | |
|<--------------------->| |
| | |
Figure 2: Prefix request
There are two function modules in the AR, DHCP Client and DHCP Relay.
Xia & Sarikaya Expires September 5, 2007 [Page 4]
Internet-Draft Prefix Delegation March 2007
DHCP messages should be relayed if the AR and a DHCP server are not
connected directly, otherwise DHCP relay function in the AR is not
necessary. Figure 2 illustrates the scenario that the AR and the
DHCP Server aren't connected directly:
1. An MS performs initial network entry and authentication
procedures.
2. On successful completion of Step 1, the AR initiates DHCP Solicit
procedure to request prefixes for the MS. The AR creates and
transmits a Solicit message as described in sections 17.1.1,
"Creation of Solicit Messages" and 17.1.2, "Transmission of
Solicit Messages" of RFC 3315. The AR creates an IA_PD and
assigns it an IAID. The AR MUST include the IA_PD option in the
Solicit message.
3. The DHCP server sends an Advertise message to the AR in the same
way as described in section 17.2.2, "Creation and transmission of
Advertise messages" of RFC 3315.
4. The AR uses the same message exchanges as described in section
18, "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to
obtain or update prefixes from a DHCP server. The AR and the
DHCP server use the IA_PD Prefix option to exchange information
about prefixes in much the same way as IA Address options are
used for assigned addresses.
5. AR stores the prefix information it received in the Reply
message.
6. A transport connection is established, and thus a virtual link is
created and becomes active. An transport connection can be
viewed as a virtual link.
7. The AR advertises prefixes to MS with RA once the virtual link is
active.
8. 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.
9. The MS starts verifying address uniqueness by sending a DAD NS on
the virtual link. AR can check the address uniqueness within the
virtual link scope.
3.2. Prefix Request Procedure for Stateful Address Configuration
After the initial network entry and authentication, a transport
connection is established for the MS. DHCPv6 client at the MS sends
DHCP Request to DHCP Relay function at AR. DHCP Relay sends DHCP
Request with DHCP Forward message to DHCP Server. AR MUST set the
link-address field of DHCP Forward to the aggregate prefix. DHCP
Server assigns an address and a unique prefix for MS and replies with
DHCP Reply message which is relayed to DHCP Relay in Relay-reply
message and AR sends DHCP Reply message with the new prefix to MS.
Xia & Sarikaya Expires September 5, 2007 [Page 5]
Internet-Draft Prefix Delegation March 2007
MS configures its interface with the address assigned by DHCP server
in DHCP Reply message.
3.3. Prefix Release Procedure
+-------+ +-------+ +-----------+
| MS | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 De-registration | |
| Handover, or others | |
|<--------------------->| |
| |2 Relay-forward/Release|
| |---------------------->|
| | |
| |3 Relay-reply/Reply |
| |<--------------------- |
| | |
| | |
Figure 3: Prefix Release
Prefixes can be released in two ways, prefix aging or DHCP release
procedure. In the former way, a prefix SHOULD not be used by an MS
when the prefix ages, and the DHCP Server can delegate it to another
MS. A prefix lifetime is delivered from the DHCPv6 server to the MS
through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information
option [I-D.ietf-ipv6-2461bis]. Figure 3 illustrates how the AR
releases prefixes to an DHCP Server which isn't connected directly:
1. An MS detachment signaling, such as switch-off or handover,
triggers prefix release procedure.
2. The AR initiates a Release message to give back the prefixes to
the DHCP server.
3. The server responds with a Reply message, and then the prefixes
can be reused by other MSs.
3.4. Renumbering
3.4.1. Renumbering Through Renew Message
To extend the valid and preferred lifetimes for the prefixes
associated with an MS, the MS sends a Renew message to the DHCP
server. The server determines new lifetimes for the prefixes. The
server MAY add new prefixes to the MS for renumbering. For a more
detailed description, see [I-D.ietf-ipv6-rfc2462bis]
Xia & Sarikaya Expires September 5, 2007 [Page 6]
Internet-Draft Prefix Delegation March 2007
3.4.2. Server Initiated Reconfiguration
DHCP server initiates a configuration message exchange with the AR by
sending a Reconfigure message. The reconfigure message triggers the
AR to send Renew message as described in Section 3.4.1.
3.5. Miscellaneous Considerations
3.5.1. Triggers for an AR to initiate prefix request procedure
There are some other triggers for an AR to initiate prefix request
procedure besides network entry and authentication, such as, when an
AR receives handover initiate (HI) message in FMIPv6 [RFC4068], or
other handover signaling. After getting an incoming MS' necessary
information (such as MAC address), the AR SHOULD initiate prefix
request procedure as soon as possible.
3.5.2. How to generate IAID
IAID is 4 bytes in length and should be unique in an AR scope. We
can use an MS' MAC address as a part to generate IAID. An IAID
generation algorithm should be designed.
3.5.3. Policy to delegate prefixes
AR should broadcast the prefix(es) dynamically upstream as the route
information of all the MSs connected to this AR. In point-to-point
links, this causes high routing protocol traffic (IGMP, OSPF, etc.)
due to Per-MS prefixes. To solve the problem, route aggregation
should be used. For example, each AR can be assigned a /48 or /32
prefix (aggregate prefix) while each MS can be assigned a /64 prefix.
The /64 prefix is an extension of /48 one, for example, an AR's /48
prefix is 3FFE:FFFF:0::/48, an MS is assigned 3FFE:FFFF:0:2::/64
prefix. The AR only broadcasts it's /48 or /32 prefix information to
Internet.
This policy can be enforced as follows: DHCP Relay MUST set the link-
address field in the Relay Forward message to the aggregate prefix
(/48, /32, or /16 prefix assigned to the AR).
4. Prefix Delegation Using RADIUS and Diameter
[I-D.ietf-radext-delegated-prefix] defines a RADIUS attribute
Delegated-IPv6-Prefix that carries an IPv6 prefix to be delegated.
This attribute is usable within either RADIUS or Diameter. In the
bootstraping procedure, an AR as RADIUS client sends Access-Request
message with an MS' information to RADIUS server. If the MS passes
Xia & Sarikaya Expires September 5, 2007 [Page 7]
Internet-Draft Prefix Delegation March 2007
the authentication, the RADIUS server sends Access-Accept message
with prefix information to the AR. The attribute MAY appear in an
Access-Request packet as a hint by the AR to the RADIUS server that
it would prefer a prefix, for example, a /48 prefix. The RADIUS
server MAY delegate a /64 prefix which is an extension of the /48
prefix in an Access-Accept message containing Delegated-IPv6-Prefix
attribute. The attribute can appear multiple times when RADIUS
server assigns multiple prefixes to MS.
When Diameter is used, an AR as Diameter client sends AA-Request
message. AA-Request message MAY contain Delegated-IPv6-Prefix
attribute. Diameter server replies with AA-Answer message. AA-
Answer message MAY contain Delegated-IPv6-Prefix attribute. The
attribute can appear multiple times when Diameter server assigns
multiple prefixes to MS. The Delegated-IPv6-Prefix attribute MAY
appear in an AA-Request packet as a hint by the AR to the Diameter
server that it would prefer a prefix, for example, a /48 prefix.
Diameter server MAY delegate in an AA-Answer message with a /64
prefix which is an extension of the /48 prefix.
For RADIUS, when the MS hands off or switches off, the AR release the
MS' prefixes through Accounting Stop message [RFC2866]. For
Diameter, the AR release prefixes through Accounting-
Request[RFC3588].
AR MUST advertize the prefix(es) to MS in RtrAdv message.
Site renumbering is an open issue for RADIUS/ Diameter protocols to
manage prefixes. [RFC3576] MAY be used for renumbering.
5. Security Considerations
This draft introduces no additional messages. Comparing to
[RFC3633], [RFC2865] and [RFC3588] there is no additional threats to
be introduced. DHCPv6, RADIUS and Diameter security procedures
apply.
6. References
6.1. Normative References
[I-D.ietf-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-ietf-16ng-ps-goals-01 (work in progress),
February 2007.
Xia & Sarikaya Expires September 5, 2007 [Page 8]
Internet-Draft Prefix Delegation March 2007
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-10 (work in progress),
January 2007.
[I-D.ietf-ipv6-rfc2462bis]
Thomson, S., "IPv6 Stateless Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08 (work in progress),
May 2005.
[I-D.ietf-radext-delegated-prefix]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-05 (work in
progress), October 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
6.2. Informative References
[I-D.ietf-16ng-ipv6-link-model-analysis]
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks",
Xia & Sarikaya Expires September 5, 2007 [Page 9]
Internet-Draft Prefix Delegation March 2007
draft-ietf-16ng-ipv6-link-model-analysis-03 (work in
progress), February 2007.
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
Xia & Sarikaya Expires September 5, 2007 [Page 10]
Internet-Draft Prefix Delegation March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 & Sarikaya Expires September 5, 2007 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 07:20:29 |