Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei USA
Expires: May 7, 2009 J. Korhonen, Ed.
TeliaSonera
S. Gundavelli
Cisco
November 3, 2008
RADIUS Proxy Mobile IPv6
draft-xia-netlmm-radius-03
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 May 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Xia, et al. Expires May 7, 2009 [Page 1]
Internet-Draft RADIUS-PMIPv6 November 2008
Abstract
This document defines a RADIUS based interface between the Mobile
Access Gateway and the RADIUS server that is used to download the per
Mobile Node Policy Profile from the remote Policy Store. The RADIUS
interactions take place when the Mobile Node attaches, authenticates
and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this
document also defines a RADIUS based interface between the Local
Mobility Anchor and the RADIUS server for authorizing received
initial Proxy Binding Update messages for the mobility service
session. In addition to the mobility session setup related RADIUS
interaction, this document defines the baseline for both the Mobile
Access Gateway and the Local Mobility Anchor generated accounting.
Xia, et al. Expires May 7, 2009 [Page 2]
Internet-Draft RADIUS-PMIPv6 November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MIP6-Feature-Vector . . . . . . . . . . . . . . . . . . . 5
4.2. Mobile-Node-Identifier . . . . . . . . . . . . . . . . . . 6
4.3. Service-Selection . . . . . . . . . . . . . . . . . . . . 7
4.4. MIP6-HA . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. MIP6-HA-FQDN . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. MIP6-HL-Prefix . . . . . . . . . . . . . . . . . . . . . . 8
4.7. MIP6-IPv4-Home-Address . . . . . . . . . . . . . . . . . . 9
4.8. PMIP6-MAG-Address . . . . . . . . . . . . . . . . . . . . 9
5. MAG to RADIUS server interface . . . . . . . . . . . . . . . . 10
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Table of Attributes . . . . . . . . . . . . . . . . . . . 11
6. LMA to RADIUS server interface . . . . . . . . . . . . . . . . 11
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Table of Attributes . . . . . . . . . . . . . . . . . . . 12
7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Accounting at LMA . . . . . . . . . . . . . . . . . . . . 12
7.2. Accounting at MAG . . . . . . . . . . . . . . . . . . . . 12
7.3. Table of Attributes . . . . . . . . . . . . . . . . . . . 13
8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Attribute Type Codes . . . . . . . . . . . . . . . . . . . 14
10.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Xia, et al. Expires May 7, 2009 [Page 3]
Internet-Draft RADIUS-PMIPv6 November 2008
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility
management protocol which allows IP mobility session continuity for a
Mobile Node (MN) without its involvement in mobility management
signaling. A Mobile Access Gateway (MAG) represents the MN and is
authorized to send mobility management signaling messages on behalf
of the MN. Before the MAG is able to perform the required mobility
management signaling, it needs to know at minimum a Local Mobility
Anchor (LMA) address and the MN Identifier (MN-ID). This per MN
Policy Profile (PP) information is stored in a Policy Store (PS),
which may be local to the MAG or accessible remotely, for example,
through an authentication, authorization and accounting (AAA)
infrastructure.
This document defines a RADIUS [RFC2865] based profile and
corresponding attributes to be used on the AAA interface between the
MAG and the RADIUS server. The interface that is used to download
the per MN Policy Profile from the remote Policy Store. The RADIUS
interactions take place when the MN attaches, authenticates and
authorizes to a PMIPv6 domain. Furthermore, this document also
defines a RADIUS based interface between the LMA and the RADIUS
server for authorizing received initial Proxy Binding Update (PBU)
messages for the mobility service session. In addition to the
mobility session setup related RADIUS interaction, this document
defines the baseline for both the MAG and the LMA generated
accounting.
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 [RFC2119].
The terminology in this document is based on the definitions found in
[RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support].
3. Solution Overview
The interface between the MAG and the RADIUS server is used to
download a Policy Profile (PP) from the RADIUS server to the MAG.
The downloading of the Policy Profile is part of the network access
authentication and authorization procedure that takes place when a MN
roams into or within a PMIPv6 domain. In this solution the MAG acts
as the Network Access Server (NAS).
Xia, et al. Expires May 7, 2009 [Page 4]
Internet-Draft RADIUS-PMIPv6 November 2008
The choice of the authentication mechanism is specific to an access
system, but could be based on the Extensible Authentication Protocol
(EAP) [RFC3748]. During the network access authentication procedure,
the MAG acting as a NAS queries the RADIUS server through the AAA
infrastructure. If the RADIUS server detects that the subscriber is
also authorized for the PMIPv6 mobility service, the subscriber
policy profile is returned along with the successful network access
authentication answer to the MAG.
After the MN has successfully been authenticated and authorized to
the network access, the MAG sends a PBU to the LMA in order to setup
or update the mobility service session for the MN. Upon receiving
the PBU the LMA interacts with the RADIUS server and fetches the
relevant subscriber policy, authorization and security information
related to the PMIPv6 mobility session. This specification assumes
that the RADIUS server is the central entity for managing everything
related to PMIPv6 subscription and mobility session, possibly even
including the allocation of Home Network Prefixes (HPN). This
specification also assumes that the Security Association (SA) between
the MAG and the LMA is already in place. How the SA is established
is outside of scope of this specification.
Due the obvious similarities between the PMIPv6 Policy Profile
download and Mobile IPv6 integrated scenario bootstrapping
[I-D.ietf-mip6-bootstrapping-integrated-dhc] this specification can
re-use several RADIUS attributes defined for Mobile IPv6 purposes
[I-D.ietf-mip6-radius]. However, some additional PMIPv6 specific
attributes and functionality is needed.
4. Attributes
4.1. MIP6-Feature-Vector
The MIP6-Feature-Vector attribute is defined in
[I-D.ietf-mip6-radius]. This document only reserves new capability
bits according to the rules in [I-D.ietf-dime-mip6-integrated]. The
following capability flag bits are defined in this document:
PMIP6_SUPPORTED (0x0000010000000000)
When the MAG/NAS sets this bit in the MIP6-Feature-Vector
attribute, it is an indication to the RADIUS server that the NAS
supports PMIPv6. When the RADIUS server sets this bit in the
response MIP6-Feature-Vector AVP, it indicates that the RADIUS
server also has PMIPv6 support. This capability flag bit can also
be used to allow PMIPv6 mobility support in a subscription
granularity.
Xia, et al. Expires May 7, 2009 [Page 5]
Internet-Draft RADIUS-PMIPv6 November 2008
IP4_HOA_SUPPORTED (0x0000020000000000)
Assignment of the IPv4-HoA is supported
[I-D.ietf-netlmm-pmip6-ipv4-support]. When the MAG sets this bit
in the MIP6-Feature-Vector attribute, it indicates that the MAG
implements a minimal functionality of a DHCP server (and a relay)
and is able to deliver IPv4-HoA to the MN. When the RADIUS server
sets this flag bit in the response MIP6-Feature-Vector attribute,
it indicates that the RADIUS server has authorized the use of
IPv4-HoA for the MN. If this bit is unset in the returned MIP6-
Feature-Vector attribute, the RADIUS server does not authorize the
configuration of IPv4 address.
LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)
Direct routing of IP packets between MNs anchored to the same MAG
is supported. When a MAG sets this flag bit in the MIP6-Feature-
Vector, it indicates that routing IP packets between MNs anchored
to the same MAG is supported, without reverse tunneling packets
via the LMA or requiring any Route Optimization related signaling
(e.g. the Return Routability Procedure in [RFC3775]) prior direct
routing. If this flag bit is unset in the returned MIP6-Feature-
Vector AVP, the RADIUS server does not authorize direct routing of
packets between MNs anchored to the same MAG. This policy feature
MUST be supported per MN and subscription basis.
The MIP6-Feature-Vector attribute is also used on the LMA to the
RADIUS server interface. Using the capability announcement attribute
it is possible to perform a simple capability negotiation between the
LMA and the RADIUS server. Those capabilities that are announced by
both parties are also known to be mutually supported.
4.2. Mobile-Node-Identifier
The Mobile-Node-Identifier attribute is of type String and contains
the mobile node identifier (MN-Identifier, see [RFC5213]) in a NAI
[RFC4282] format. This AVP is used on the MAG to the RADIUS server
interface.
The Mobile-Node-Identifier attribute is returned in the Access-Accept
message that ends a successful authentication (and possibly an
authorization) exchange between the MAG and the RADIUS server,
assuming the RADIUS server is also able to provide the MAG with a MN-
Identifier that guarantees mobility session continuity in the first
place. The MAG SHOULD use the received MN-Identifier as the MN-ID in
the subsequent PBUs. The MAG is allowed to discard the RADIUS server
provided identity if it has other means of finding out a MN-ID that
Xia, et al. Expires May 7, 2009 [Page 6]
Internet-Draft RADIUS-PMIPv6 November 2008
guarantees mobility session continuity.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mobile Node Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
MOBILE-NODE-IDENTIFIER-TYPE to be defined by IANA.
Length:
>= 3 octets
Mobile Node Identifier:
This field is of type String and contains the MN-ID
of the MN to be used in the PBUs.
Editor's note:
4.3. Service-Selection
The Service-Selection attribute is of type String, encoded as UTF-8
[RFC3629], and contains the name of the service or the external
network that the mobility service should be associated with. The
RADIUS server MAY return the Service-Selection attribute to the MAG
and in that way indicate the default service to the MAG. Between the
LMA to the RADIUS server interface, the LMA MAY populate the Service-
Selection attribute with the service information found from the
received PBU, if such information is available [RFC5149].
Xia, et al. Expires May 7, 2009 [Page 7]
Internet-Draft RADIUS-PMIPv6 November 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Service Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
SERVICE-SELECTION-TYPE to be defined by IANA.
Length:
>= 3 octets
Service Identifier:
This field is of type String and contains the Service Identifier
the MN MUST be associated with. This specification allows
international identifier strings that are based on the use of
Unicode characters, encoded as UTF-8 [RFC3629].
Editor's note: we might need to address normalization here.
4.4. MIP6-HA
The MIP6-HA attribute is defined in [I-D.ietf-mip6-radius]. In the
scope of this specification the attribute contains an IPv6 address of
the LMA in the network byte order.
Editor's note: we probably should also define an attribute to carry
IPv4 address of the LMA. Or then we could always use "IPv4-
compatible IPv6 address" to carry the IPv4 address of the LMA.
4.5. MIP6-HA-FQDN
The MIP6-HA-FQDN attribute is defined in [I-D.ietf-mip6-radius]. In
the scope of this specification the attribute contains a Fully
Qualified Domain Name (FQDN) of the LMA.
4.6. MIP6-HL-Prefix
The MIP6-HL-Prefix attribute is defined in [I-D.ietf-mip6-radius].
In the scope of this specification the attribute contains the MN-HNP
of the MN in the network byte order. The low 64 bits of the IPv6
address MUST be all zeroes. The high 64 bits of the IPv6 address are
used as the MN-HNP. The primary use of this AVP is to carry the IPv6
Home Network Prefix, if available, from the RADIUS server to the MAG.
Xia, et al. Expires May 7, 2009 [Page 8]
Internet-Draft RADIUS-PMIPv6 November 2008
4.7. MIP6-IPv4-Home-Address
The MIP6-IPv4-Home-Address attribute is of type Address and contains
the IPv4-HoA of the MN in the network byte order. The primary use of
this attribute is to carry the IPv4-HoA
[I-D.ietf-netlmm-pmip6-ipv4-support], if available, from the RADIUS
server to the MAG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
MIP6-IPV4-HOME-ADDRESS-TYPE to be defined by IANA.
Length:
= 6 octets
Address:
This field is of type Address and contains the IPv4 Home
Address of the MN.
4.8. PMIP6-MAG-Address
The PMIP6-MAG-Address attribute is of type String and contains the
IPv6 address of the MAG in the network byte order. This attribute is
mainly useful for collecting statistics information about MN's
movement.
Xia, et al. Expires May 7, 2009 [Page 9]
Internet-Draft RADIUS-PMIPv6 November 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
PMIP6-MAG-ADDRESS-TYPE to be defined by IANA.
Length:
= 18 octets
Address:
This field is of type String and contains the IPv6 Address
of the MAG in network byte order.
5. MAG to RADIUS server interface
5.1. General
The MAG to the RADIUS server interface is primarily used for
downloading the Policy Profile (i.e., to bootstrap the PMIPv6
mobility service session) when a MN attaches, authenticates and
authorizes to a PMIPv6 domain. Whenever the MAG sends a RADIUS
request message to the RADIUS server, the User-Name attribute SHOULD
contain the MN identity. At minimum the home network realm of the MN
MUST be available at the MAG when the network access authentication
takes place. Otherwise the MAG is not able to route the RADIUS
request messages towards the correct RADIUS server. The MN identity
MUST be in Network Access Identifier (NAI) [RFC4282] format.
Xia, et al. Expires May 7, 2009 [Page 10]
Internet-Draft RADIUS-PMIPv6 November 2008
5.2. Table of Attributes
The following table provides a guide to which PMIPv6 specific
attributes SHOULD be included in RADIUS messages during the
authentication and authorization process.
Request Accept Reject Challenge # Attribute
0 0-1 0 0 TBD MIP6-HA
0 0-1 0 0 TBD MIP6-HA-FQDN
0 0-1 0 0 TBD MIP6-HL-Prefix
0 0-1 0 0 TBD MIP6-IPv4-Home-Address
0-1 0-1 0 0 TBD MIP6-Feature-Vector
0-1 0-1 0 0 TBD Service-Selection
0 1 0 0 TBD Mobile-Node-Identifier
6. LMA to RADIUS server interface
6.1. General
The LMA to the RADIUS server interface may be used for multiple
purposes. These include the authorization of the incoming PBU,
dynamic allocation of the MN-HNP from address pools managed by the
RADIUS server, updating the RADIUS server with the LMA address in the
case the LMA was dynamically allocated by the MAG, possible MAG to
LMA Security Association security related information retrieval,
accounting and PMIPv6 session management.
Whenever the LMA sends a RADIUS request message to the RADIUS server,
the User-Name attribute MUST contain the MN identity. The identity
MUST be in a NAI format. The LMA MAY retrieve the MN identity
information from the PBU MN-ID mobility option.
If the PBU contains the MN Link-Layer Identifier option, the Calling-
Station-Id attribute SHOULD be included in the request message
containing the received Link-Layer Identifier. Furthermore, if the
PBU contains the Service Selection mobility option [RFC5149], the
Service-Selection attribute SHOULD be included in the request message
containing the received service identifier.
The LMA and the RADIUS server use the MIP6-HL-Prefix attribute to
exchange the MN-HNP when appropriate. The low 64 bits of the prefix
must be all zeroes. Similarly, the LMA and the RADIUS server use the
MIP6-IPv4-Home-Address attribute to exchange the MN IPv4-HoA when
appropriate. If the MIP6-HL-Prefix is set to an all zeroes address
(i.e., 0::0) in the request message, it is an indication that the
Xia, et al. Expires May 7, 2009 [Page 11]
Internet-Draft RADIUS-PMIPv6 November 2008
RADIUS server needs to assign the MN-HNP and return it to the LMA in
the response message. If the MIP6-IPv4-Home-Address is set to all
zeroes (i.e., 0.0.0.0) in the request message, it is an indication
that the RADIUS server needs to assign the MN IPv4-HoA and return it
to the LMA in the response message.
6.2. Table of Attributes
The following table provides a guide to which PMIPv6 specific
attributes SHOULD be included in the RADIUS messages during the
authorization process.
Request Accept Reject Challenge # Attribute
1 0 0 0 TBD MIP6-HA
0-1 0 0 0 TBD MIP6-HL-Prefix
0-1 0 0 0 TBD MIP6-IPv4-Home-Address
0-1 0-1 0 0 TBD MIP6-Feature-Vector
0-1 0 0 0 TBD Service-Selection
1 0 0 0 TBD Mobile-Node-Identifier
1 0 0 0 TBD PMIP6-MAG-Address
0-1 0 0 0 31 Calling-Station-Id
7. Accounting
Editor's note: these sections will be revised.
7.1. Accounting at LMA
The accounting at the LMA to AAA server interface is based on
[RFC2865] and [RFC2866]. The interface must support the transfer of
accounting records needed for service control and charging. These
include (but may not be limited to): time of binding cache entry
creation and deletion, octets sent and received by the MN in bi-
directional tunneling, etc.
7.2. Accounting at MAG
The accounting at the MAG to AAA server interface is based on
[RFC2865] and [RFC2866]. The interface must also support the
transfer of accounting records which include: time of binding cache
entry creation and deletion, octets sent and received by the MN in
bi-directional tunneling, etc.
If there is data traffic between a visiting mobile node and a
correspondent node that is locally attached to an access link
Xia, et al. Expires May 7, 2009 [Page 12]
Internet-Draft RADIUS-PMIPv6 November 2008
connected to the mobile access gateway, the mobile access gateway MAY
optimize on the delivery efforts by locally routing the packets and
by not reverse tunneling them to the mobile node's local mobility
anchor. In this case, local data traffic MUST be reported to AAA
servers through RADIUS protocol.
7.3. Table of Attributes
The following table provides a guide to which attributes may be found
in accounting messages.
Request Interim Stop Attribute
0-1 0 0-1 MIP6-HA
0-1 0 0-1 MIP6-HL-Prefix
0-1 0 0-1 MIP6-IPv4-Home-Address
0-1 0 0-1 Service-Selection
0-1 0 0-1 MIP6-Feature-Vector
0-1 0-1 0-1 Mobile-Node-Identifier
0-1 0 0-1 Calling-Station-Id
0-1 0-1 0-1 PMIP6-MAG-Address
8. Diameter Considerations
Editor's note: The Diameter compatibility requires further work. It
needs to be evaluated, which attributes could be used as-is in
Diameter specification for equivalent purposes. Such alignment could
ease the possible RADIUS-Diameter translation agent functionality
considerably.
9. Security Considerations
The security considerations of the RADIUS protocol [RFC2865], are
applicable to this document. The RADIUS messages may be transported
between the MAG and/or the LMA to the RADIUS server via one or more
AAA brokers or RADIUS proxies. In this case the HA to the RADIUS
server AAA communication rely on the security properties of the
intermediate AAA brokers and RADIUS proxies.
This document does not introduce any new security vulnerabilities
that would not already have been identified in Mobile IPv6 integrated
scenario bootstrapping [I-D.ietf-mip6-bootstrapping-integrated-dhc]
and its use of AAA [I-D.ietf-dime-mip6-integrated].
Xia, et al. Expires May 7, 2009 [Page 13]
Internet-Draft RADIUS-PMIPv6 November 2008
10. IANA consideration
10.1. Attribute Type Codes
This specification defines the following new RADIUS attribute type
codes:
MIP6-IPV4-HOME-ADDRESS-TYPE is set to TBD
SERVICE-SELECTION-TYPE is set to TBD
MOBILE-NODE-IDENTIFIER-TYPE is set to TBD
PMIP6-MAG-ADDRESS-TYPE is set to TBD
10.2. Namespaces
This specification defines new values to the Mobility Capability
registry (see [I-D.ietf-dime-mip6-integrated]) for use with the MIP6-
Feature-Vector AVP:
Token | Value | Description
----------------------------------+----------------------+------------
PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD]
IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD]
LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD]
Xia, et al. Expires May 7, 2009 [Page 14]
Internet-Draft RADIUS-PMIPv6 November 2008
11. Acknowledgements
The authors would like to thank the authors of
[I-D.ietf-mip6-radius], [I-D.ietf-dime-mip6-integrated] and
[I-D.korhonen-dime-pmip6] as this specification re-uses attributes
and some procedural ideas of the mentioned specifications.
Xia, et al. Expires May 7, 2009 [Page 15]
Internet-Draft RADIUS-PMIPv6 November 2008
12. References
12.1. Normative References
[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.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[I-D.ietf-mip6-radius]
Lior, A., Chowdhury, K., and H. Tschofenig, "RADIUS Mobile
IPv6 Support", draft-ietf-mip6-radius-05 (work in
progress), July 2008.
[I-D.ietf-dime-mip6-integrated]
Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-10 (work in progress),
September 2008.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
12.2. Informative references
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Xia, et al. Expires May 7, 2009 [Page 16]
Internet-Draft RADIUS-PMIPv6 November 2008
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05
(work in progress), September 2008.
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[I-D.korhonen-dime-pmip6]
Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Support For
Mobile Access Gateway and Local Mobility Anchor to
Diameter Server Interaction", draft-korhonen-dime-pmip6-04
(work in progress), September 2008.
Xia, et al. Expires May 7, 2009 [Page 17]
Internet-Draft RADIUS-PMIPv6 November 2008
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Jouni Korhonen (editor)
TeliaSonera
Email: jouni.nospam@gmail.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
Email: sgundave@cisco.com
Xia, et al. Expires May 7, 2009 [Page 18]
Internet-Draft RADIUS-PMIPv6 November 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).
Xia, et al. Expires May 7, 2009 [Page 19]