Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: August 25, 2008 Huawei USA
J. Korhonen
TeliaSonera Corporation
February 22, 2008
Problem Statement and Requirements for Diameter Prefix Delegation
Application
draft-sarikaya-dime-prefix-delegation-ps-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 August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Sarikaya, et al. Expires August 25, 2008 [Page 1]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
Abstract
This document provides problem statement for Diameter prefix
delegation application. The document also identifies application
scenarios and requirements on Diameter prefix delegation application.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
4.1. Prefix Management in Access Routers . . . . . . . . . . . 4
4.2. Prefix Management in Local Mobility Anchors . . . . . . . 5
4.3. Prefix Management for Mobile Routers . . . . . . . . . . . 5
5. Requirements on AAA-based Prefix Delegation Application . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Sarikaya, et al. Expires August 25, 2008 [Page 2]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
1. Introduction and Motivation
Prefix assignment for an IPv6 node (host or router) is essential to
IPv6 address formulation. Even though IPv6 address space is large
enough, it still makes sense for operators to manage addresses in a
central way, e.g. using central DHCPv6 servers or AAA servers.
Delegating prefix from a central server to a prefix user (e.g. a
router) needs communication between different network entities.
Prefix delegation is widely discussed in IETF 16NG, NEMO, and NETLMM
Working Groups. Corresponding solutions are also introduced. But
these solutions only solve a part of the problem. In 16NG, an Access
Router allocates a mobile node's prefix using Router Advertisement
message defined in [RFC4861]. There is no discussion about how the
Access Router acquires prefixes from external entity. NEMO deals
with synchronization of Mobile Network prefixes between a Mobile
Router and a Home Agent, while the method is agnostic to the way that
a Home Agent gets prefixes from back end servers. In Proxy Mobile
IPv6 [I-D.ietf-netlmm-proxymip6], Proxy Binding Update and Proxy
Binding Acknowledgement messages are used to allocate prefixes from a
Local Mobile Anchor to a mobile node, but how the Local Mobile Anchor
gets prefixes from external server is out of the scope.
[RFC3633] defines Prefix Delegation options and procedures to provide
a mechanism for automated delegation of IPv6 prefixes using the
Dynamic Host Configuration Protocol (DHCP). But there is no existing
mechanism to manage prefixes dynamically by an AAA server.
Making use of AAA infrastructure for prefix management can solve the
aforementioned problems in a uniform way.
2. Terminology
Prefix Delegation (PD): The process by which a router obtains a
prefix dynamically.
3. Problem Statement
AAA servers managing IP address is a convention. [RFC2865] defines
attribute Framed-IP-Address for allocating IPv4 address for a host.
AAA servers statically configuring IPv6 prefixes is also a
convention. [RFC3162] introduces Framed-IPv6-Prefix attribute for
configuring IPv6 prefixes for a host. This configuration is static
because Framed-IPv6-Prefix carries a number of prefixes only.
Lifetime values for each prefix can not be carried.
Sarikaya, et al. Expires August 25, 2008 [Page 3]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix
delegation. [RFC4818] designs Delegated-IPv6-Prefix attribute which
is used for delegating prefixes. However in [RFC4818], the
recommended usage scenario is AAA server configures the delegating
server with some prefixes and then DHCP Prefix Delegation [RFC3633]
can be used to delegate these prefixes to the requesting router.
Also Delegated-IPv6-Prefix carries a number of prefixes only.
Lifetime values for each prefix can not be carried.
In a prefix delegation application, the requesting router requests
prefixes from the delegating server. The delegating server replies
with one or more prefixes. When the lifetime of the prefix(es)
expires, the requesting router renews its request for the prefix(es).
4. Application Scenarios
Diameter prefix delegation application has the applications that are
described in this section.
4.1. Prefix Management in Access Routers
[RFC4968] provides different IPv6 link models that are suitable for
IEEE 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. As to IPv6 addressing,
there are two models, shared link model and point-to-point link
model. In the former model, an IPv6 prefix is shared by multiple
MNs. While in the latter model, a prefix is only assigned to one
interface of MN. Different MNs can't share a prefix, and an
interface can have multiple prefixes. [RFC5121] specifies the
addressing and operation of IPv6 over the IPv6 specific part of the
packet convergence sub-layer of IEEE Std 802.16e [802.16e], and
point-to-point link model is recommended.
Also, 3GPP/3GPP2 have earlier adopted the point-to-point link model
[RFC3314].
A mobile node and an Access Router are connected via a point-to-point
connection at the IPv6 layer. Hence each mobile node can be
considered to be on a separate subnet. The prefixes for the mobile
node are advertised through Router Advertisement message [RFC4861].
When an MN attaches an Access Router(AR), the AR requests one or more
prefixes for the MN from an external server or a local prefix pool.
When the MN detaches the AR, the prefixes should be released. When
an operator wants to renumber its network, prefixes with different
lifetime are advertised to the MN.
Sarikaya, et al. Expires August 25, 2008 [Page 4]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
Diameter prefix delegation application can be the mechanism to deal
with how AR acquires and manages these prefixes.
4.2. Prefix Management in Local Mobility Anchors
[I-D.ietf-netlmm-proxymip6] enables mobility support to a host
without requiring its participation in any mobility related
signaling. Point-to-point access link is supported. It assumes that
the mobile node and the Mobile Access Gateway (MAG) are the only two
nodes on the access link. Figure 1 shows a typical process for MN to
request it's home network prefix.
MN MAG LMA Server
|------>| | | 1. RtSol
| |------->| | 2. PBU (HNP=0)
| | |<------>| 3. Prefix Exchange
| |<-------| | 4. PBA (HNP)
|<------| | | 5. RA(HNP)
Figure 1: Prefix Delegation in Proxy Mobile IPv6
1. An MN solicits a router advertisement (RtSol) for stateless
address configuration.
2. The Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU)
message to Local Mobility Anchor (LMA) and with Home Network
Prefix (HNP) to zero.
3. No details are provided in [I-D.ietf-netlmm-proxymip6] on how LMA
manages prefixes. This is one of the motivations to design a
Diameter application for prefix delegation.
4. The LMA replies PBU with Proxy Binding Acknowledgement (PBA) and
sets MN's prefix to HNP field of PBA.
5. MAG advertises prefixes to MN with Router Advertisement (RA) for
stateless address configuration.
4.3. Prefix Management for Mobile Routers
[I-D.ietf-nemo-prefix-delegation] specifies mechanism for a Mobile
Router(MR) to synchronize its Mobile Network Prefixes with its Home
Agents and obtain new ones dynamically. Figure 2 shows the process
that a Mobile Router requests prefixes from a Home Agent.
Sarikaya, et al. Expires August 25, 2008 [Page 5]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
MR HA Server
| | |
|------->| | 1. BU
| | |
| |<------>| 2. Prefix Exchange
| | |
|<-------| | 3. BA
| | |
Figure 2: Prefix Delegation in NEMO
1. Mobile Network Prefix request option defined in
[I-D.ietf-nemo-prefix-delegation] is included in the Binding
Update(BU) to indicate to the Home Agent(HA) that the MR wishes
to get new prefixes assigned to it for use as Mobile Networks
Prefixes.
2. The HA requests prefix from an external entity. There is no
further description in [I-D.ietf-nemo-prefix-delegation]. The
problem can also be solved by defining a new Diameter
application.
3. Mobile Network Prefix Confirm option defined in
[I-D.ietf-nemo-prefix-delegation] is included in the Binding
Acknowledgement to allocate prefixes to the MR.
Mobile Network Prefix Confirm option carries the prefix lifetime.
Prefixes can be refreshed either by MR sending a BU or by HA sending
a BA.
5. Requirements on AAA-based Prefix Delegation Application
AAA-based prefix delegation (PD) application MUST run between a
requesting router (RR), e.g. AR, LMA, MR, etc. and a delegating
server (DS) which MUST be AAA server.
AAA-based PD application MUST support the AAA client as RR to request
prefixes from an AAA server as DS. AAA-based PD application MUST
support the client as RR to give back the prefixes to AAA server as
DS.
If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices
connected to the requesting router (RR), the certificate or the
information needed to obtain a certificate entitling RR to advertise
the prefix delegated to it SHOULD be sent by the delegating router.
In point-to-point link operation, the requesting router MUST identify
the interface of MN in its request. The requesting router MAY
Sarikaya, et al. Expires August 25, 2008 [Page 6]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
provide a prefix hint, e.g. of length /48 to which the delegating
server MUST reply with one or more prefixes, e.g. of length /64.
In point-to-point operation, the delegating server MAY assign the
prefix(es) and related parameters such as the lifetime and the
certificates to MN from MN's profile.
AAA-based prefix delegation application SHOULD support prefix release
procedures.
The AAA client as RR is responsible for renewing the prefixes when
the lifetime expires. The AAA client as RR SHOULD be able to extend
the lifetime of the prefixes using messages designed for this
purpose.
It SHOULD be possible to renumber the prefixes delegated by AAA
server. The AAA server as DS SHOULD initiate prefix renumbering
process.
6. Security Considerations
This document is a problem statement that does not by itself
introduce any security issues.
7. IANA Considerations
None.
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Sarikaya, et al. Expires August 25, 2008 [Page 7]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
9.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
[I-D.ietf-nemo-prefix-delegation]
Kniveton, T. and P. Thubert, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-02 (work in
progress), August 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-10 (work in progress),
February 2008.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
Sarikaya, et al. Expires August 25, 2008 [Page 8]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Jouni Korhonen
TeliaSonera Corporation
P.O.Box 970
FI-00051 Sonera, FINLAND
Email: Jouni.korhonen@teliasonera.com
Sarikaya, et al. Expires August 25, 2008 [Page 9]
Internet-Draft PS:Diameter Prefix Delegation Application February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
Sarikaya, et al. Expires August 25, 2008 [Page 10]