One document matched: draft-ietf-dime-mip6-integrated-09.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC4004 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4004.xml'>
<!ENTITY RFC4005 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml'>
<!ENTITY RFC4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY I-D.ietf-mext-aaa-ha-goals PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-aaa-ha-goals.xml'>
<!ENTITY I-D.ietf-mip6-bootstrapping-integrated-dhc PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-bootstrapping-integrated-dhc.xml'>
<!ENTITY RFC3753 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3753.xml'>
<!ENTITY RFC2136 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
<!ENTITY RFC4640 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4640.xml'>
<!ENTITY RFC3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY RFC4186 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4186.xml'>
<!ENTITY RFC5026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026.xml'>
<!ENTITY I-D.ietf-mext-nemo-v4traversal PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-v4traversal.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="full3978" category="std" docName="draft-ietf-dime-mip6-integrated-09.txt">
<front>
<title abbrev="Diameter MIPv6 NAS to HAAA Interaction">Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction</title>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization>TeliaSonera</organization>
<address>
<postal>
<street>Teollisuuskatu 13</street>
<city>Sonera</city>
<code>FIN-00051</code>
<country>Finland</country>
</postal>
<email>jouni.korhonen@teliasonera.com</email>
</address>
</author>
<author fullname="Julien Bournelle" surname="Bournelle" initials="J.">
<organization>Orange Labs</organization>
<address>
<postal>
<street>38-4O rue du general Leclerc</street>
<city>Issy-Les-Moulineaux</city>
<code>92794</code>
<country>France</country>
</postal>
<email>julien.bournelle@orange-ftgroup.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="C. E." surname="Perkins" fullname="Charles E. Perkins">
<organization/>
<!--organization abbrev="Nokia">Palo Alto Systems Research Center</organization-->
<address>
<!--postal>
<street>975 Page Mill Road, Suite 200</street>
<city>Palo Alto</city>
<code>CA 94304-1003</code>
<country>USA</country>
</postal-->
<email>charliep@computer.org</email>
<phone>+1-650-496-4402</phone>
</address>
</author>
<author initials="K." surname="Chowdhury" fullname="Kuntal Chowdhury">
<organization>Starent Networks</organization>
<address>
<postal>
<street>30 International Place</street>
<city>Tewksbury</city>
<code>MA 01876</code>
<country>US</country>
</postal>
<email>kchowdhury@starentnetworks.com</email>
<phone>+1 214 550 1416</phone>
</address>
</author>
<date year="2008"/>
<area>Operations and Management</area>
<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Diameter</keyword>
<keyword>Mobile IPv6</keyword>
<keyword>Integrated Scenario</keyword>
<abstract>
<t>A Mobile IPv6 node requires a home agent address, a home address, and a security
association with its home agent before it can start utilizing Mobile IPv6. RFC 3775
requires that some or all of these parameters are statically configured. Mobile IPv6
bootstrapping work aims to make this information dynamically available to the Mobile
Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support
interworking with existing authentication, authorization and accounting infrastructure.
This document describes the MIPv6 bootstrapping using the Diameter Network Access Server
(NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>The Mobile IPv6 (MIPv6) specification <xref target="RFC3775"/> requires a Mobile Node
(MN) to perform registration with a home agent (HA) with information about its current
point of attachment (care-of address). The HA creates and maintains binding between the
MN's Home Address and the MN's Care-of Address. </t>
<t>In order to register with a HA, the MN needs to know some information such as the Home
Link prefix, the HA address, the Home Address(es), the Home Link prefix length and
security association related information. </t>
<t>The aforementioned information may be statically configured. However, static
provisioning becomes an administrative burden for an operator. Moreover, it does not
address load balancing, failover, opportunistic home link assignment and assignment of
local HAs in close proximity to the MN. Also the ability to react to sudden
environmental or topological changes is minimal. Static provisioning may not be
desirable, in light of these limitations. </t>
<t>Dynamic assignment of MIPv6 home registration information is a desirable feature for
ease of deployment and network maintenance. For this purpose, the AAA infrastructure,
which is used for access authentication, can be leveraged to assign some or all of the
necessary parameters. The Diameter server in Access Service Provider's (ASP) or in
Mobility Service Provider's (MSP) network may return these parameters to the AAA client.
Regarding the bootstrapping procedures, the AAA client might either be the NAS, in case
of the integrated scenario, or the HA, in case of the split scenario <xref
target="RFC5026"/>. The terms integrated and split are described in the terminology
section and were introduced in <xref target="RFC4640"/> and <xref
target="I-D.ietf-mext-aaa-ha-goals"/>. </t>
</section>
<!-- ====================================================================== -->
<section anchor="terms" title="Terminology and Abbreviations">
<t>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 <xref target="RFC2119"/>. </t>
<t>General mobility terminology can be found in <xref target="RFC3753"/>. The following
additional terms, as defined in <xref target="RFC4640"/>, are used in this document: </t>
<t>
<list style="hanging">
<t hangText="Access Service Authorizer (ASA):">
<vspace blankLines="1"/>A network operator that authenticates a MN and establishes
the MN's authorization to receive Internet service. </t>
<vspace blankLines="1"/>
<t hangText="Access Service Provider (ASP):">
<vspace blankLines="1"/> A network operator that provides direct IP packet
forwarding to and from the MN. </t>
<vspace blankLines="1"/>
<t hangText="Mobility Service Authorizer (MSA):">
<vspace blankLines="1"/> A service provider that authorizes MIPv6 service. </t>
<vspace blankLines="1"/>
<t hangText="Mobility Service Provider (MSP):">
<vspace blankLines="1"/>A service provider that provides MIPv6 service. In order
to obtain such service, the MN must be authenticated and authorized to obtain the
MIPv6 service. </t>
<vspace blankLines="1"/>
<t hangText="Split scenario:">
<vspace blankLines="1"/>A scenario where the mobility service and the network
access service are authorized by different entities. </t>
<vspace blankLines="1"/>
<t hangText="Integrated Scenario:">
<vspace blankLines="1"/> A scenario where the mobility service and the network
access service are authorized by the same entity. </t>
<vspace blankLines="1"/>
<t hangText="Network Access Server (NAS):">
<vspace blankLines="1"/>A device that provides an access service for a user to a
network. </t>
<vspace blankLines="1"/>
<t hangText="Home AAA (HAAA):">
<vspace blankLines="1"/> An authentication, authorization and accounting server
located in user's home network i.e., in the home realm. </t>
<vspace blankLines="1"/>
<t hangText="Local AAA (LAAA):">
<vspace blankLines="1"/> An authentication, authorization and accounting proxy
located in the local (ASP) network. </t>
<vspace blankLines="1"/>
<t hangText="Visited AAA (VAAA):">
<vspace blankLines="1"/> An authentication, authorization and accounting proxy
located in a visited network i.e., in the visited realm. In a roaming case, the
local Diameter proxy has the VAAA role.</t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="Overview">
<t>This document addresses the authentication, authorization and accounting functionality
required for the MIPv6 bootstrapping solutions outlined in <xref target="RFC4640"/> and
focuses on the Diameter based AAA functionality for the NAS to HAAA communication. </t>
<t>In the integrated scenario MIPv6 bootstrapping is provided as part of the network access
authentication procedure. <xref target="integrated-scenario"/> shows the participating
entities. </t>
<t>
<figure anchor="integrated-scenario"
title="Mobile IPv6
Bootstrapping in the Integrated Scenario">
<artwork><![CDATA[
+---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(MSP) |
|(Mobility Service Provider)| | |
| | | |
| +--------+ | | +--------+ |
| |Local | Diameter | | |Home | |
| |Diameter|<---------------------->|Diameter| |
| |Proxy | (*) | | |Server | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ |
| | | | | |(+) |
| | | | | | |
| Diameter | | v |
| | |(+) +-------+ | | +-------+ |
| | | |Home | | | |Home | |
| | +-------->|Agent | | | |Agent | |
| (*)| |in ASP | | | |in MSP | |
| v +-------+ | | +-------+ |
+-------+ IEEE | +-----------+ +-------+ | +-----------------+
|Mobile | 802.1X | |NAS/Relay | |DHCPv6 | |
|Node |------------|Diameter |---|Server | |
| | PANA,... | |Client |(+)| | |
+-------+ DHCP | +-----------+ +-------+ |
(+) +---------------------------+
Legend:
(*): Functionality in scope of this specification
(+): Extensions described in other documents.
]]></artwork>
</figure>
</t>
<t>In a typical MIPv6 access scenario, a MN is attached to an
ASP's network. During the network attachment procedure,
the MN interacts with the NAS/Diameter
client. Subsequently, the NAS/Diameter client interacts
with the Diameter server over the NAS to HAAA interface.
</t>
<t>When the Diameter server performs the authentication and
authorization for the network access it
also determines whether the user is authorized to the
MIPv6 service. Based on the MIPv6 service authorization
and user's policy profile,
the Diameter server may return several MIPv6
bootstrapping related parameters to the NAS. The NAS to
HAAA interface described in this document is not tied to
DHCPv6 as the only mechanism to convey MIPv6 related
configuration parameters from the NAS/Diameter client to the
mobile node.
</t>
</section>
<!-- ====================================================================== -->
<section anchor="cmds" title="Commands, AVPs and Advertising Application Support">
<section anchor="apps" title="Advertising Application Support">
<t>This document does not define a new application. On the
other hand it defines a number of MIPv6 bootstrapping
NAS to HAAA interface (integrated scenario) related
AVPs. These AVPs can be used with present and future Diameter
applications, where permitted by the command ABNF. The
examples using existing applications and their commands
in the following sections are for informational
purposes only. The examples in this document reuse
EAP <xref target="RFC4072"/> application and its respective
commands.
</t>
</section>
<section title="Command Codes">
<t> This document shows re-use of the Diameter EAP
application commands <xref target="RFC4072"/> as an
example of the MIPv6 bootstrapping NAS to HAAA
interface. Refer to <xref target="nasavpoccurance"/>
and <xref target="nasavptable"/> for AVP
occurance definitions in Diameter commands. The
following commands are used to carry
MIPv6 related bootstrapping AVPs: </t>
<t>
<figure anchor="cmd"
title="MIPv6 Bootstrapping NAS to HAAA Interface
Command Codes">
<artwork><![CDATA[
Command-Name Abbrev. Code Reference Application
Diameter-EAP-Request DER 268 RFC 4072 EAP
Diameter-EAP-Answer DEA 268 RFC 4072 EAP
]]></artwork>
</figure>
</t>
<t>When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request
(STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR),
Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA)
commands are used together with the MIPv6 bootstrapping NAS to HAAA interface, they
follow the rules defined in RFC 3588 <xref target="RFC3588"/> and the rules for the
specific Diameter application the AVPs defined in this document are used with. The
accounting commands use the Application Identifier value of 3 (Diameter Base
Accounting); the others use 0 (Diameter Common Messages). </t>
<t>All request messages SHOULD contain the User-Name AVP containing the identity of the
MN in NAI format. It is out of scope how the NAS finds out the MN identity. The NAS
could, for example, use the MN identity provided by the network access authentication
mechanism. </t>
</section>
<section title="Diameter-EAP-Request (DER)">
<t>The Diameter-EAP-Request (DER) message <xref target="RFC4072"/>, indicated by the
Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is
sent by the NAS to the Diameter server to initiate a network access authentication
and authorization procedure. The DER message format is the same as defined in <xref
target="RFC4072"/>. The message MAY include optional MIPv6 bootstrapping AVPs: <artwork><![CDATA[
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
* [ MIP6-Agent-Info ]
* [ MIP6-Home-Link-Prefix ]
[ MIP6-Feature-Vector ]
[ User-Name ]
[ Destination-Host ]
...
* [ AVP ]
]]></artwork>
</t>
</section>
<section title="Diameter-EAP-Answer (DEA)">
<t>The Diameter-EAP-Answer (DEA) message defined in <xref target="RFC4072"/>, indicated
by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field,
is sent in response to the Diameter-EAP-Request message (DER). If the network access
authentication procedure was successful then the response MAY include any set of
bootstrapping AVPs. </t>
<t>The DEA message format is the same as defined in <xref target="RFC4072"/> with an
addition of optional MIPv6 bootstrapping AVPs: <artwork><![CDATA[
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
* [ MIP6-Agent-Info ]
* [ MIP6-Home-Link-Prefix ]
[ MIP6-Feature-Vector ]
[ User-Name ]
...
* [ AVP ]
]]></artwork>
</t>
</section>
<!--section title="AA-Request (AAR)">
<t>The AA-Request (AAR) message <xref target="RFC4005"/>, indicated by the Command-Code
field set to 265 and 'R' bit set in the Command Flags field, is sent by the NAS to
the Diameter server to initiate a network access authentication and authorization
procedure. The AAR message format is the same as defined in <xref target="RFC4005"/>.
The message MAY include optional MIPv6 bootstrapping AVPs: <artwork><![CDATA[
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
* [ MIP6-Agent-Info ]
* [ MIP6-Home-Link-Prefix ]
[ MIP6-Feature-Vector ]
[ User-Name ]
[ Destination-Host ]
...
* [ AVP ]
]]></artwork>
</t>
</section>
<section title="AA-Answer (AAA)">
<t>The AA-Answer (AAA) message, indicated by the Command-Code field set to 265 and 'R'
bit cleared in the Command Flags field is sent in response to the AA-Request (AAR)
message for confirmation of the result of MIPv6 HA bootstrapping. If the network
access authentication procedure was successful then the response MAY include any set
of bootstrapping AVPs. </t>
<t>The AAA message format is the same as defined in <xref target="RFC4005"/> with an
addition of optional MIPv6 bootstrapping AVPs: <artwork><![CDATA[
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
* [ MIP6-Agent-Info ]
* [ MIP6-Home-Link-Prefix ]
[ MIP6-Feature-Vector ]
[ User-Name ]
...
* [ AVP ]
]]></artwork>
</t>
</section -->
<section title="Attribute Value Pair Definitions">
<section title="MIP6-Agent-Info">
<t>The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and contains necessary
information to assign a HA to the MN. When the MIP6-Agent-Info AVP is present in a
message, it MUST contain either the MIP-Home-Agent-Address AVP or the
MIP-Home-Agent-Host AVP, or both AVPs. The grouped AVP has the following grammar: <artwork><![CDATA[
<MIP6-Agent-Info> ::= < AVP Header: TBD >
[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ]
* [ AVP ]
]]></artwork>
</t>
<t>If both MIP-Home-Agent-Address and
MIP-Home-Agent-Host APVs are present in the
MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD
have a precedence over the MIP-Home-Agent-Host. The
reason for this recommendation is that the
MIP-Home-Agent-Address points to a specific home
agent, where as the MIP-Home-Agent-Host may point to
a group of HAs located at within the same realm.
A Diameter client or an agent may use
the MIP-Home-Agent-Host AVP, for instance, to find
out the realm where the HA is located.
</t>
<t>This AVP MAY also be attached by the NAS or by intermediating Diameter
proxies in a request message when sent to the Diameter server
as a hint of a locally assigned HA. This AVP MAY also be attached by the
intermediating Diameter proxies in a reply message from the Diameter server,
if locally assigned HAs are authorized by the Diameter server.
</t>
</section>
<section title="MIP-Home-Agent-Address AVP">
<t>The MIP-Home-Agent-Address AVP (AVP Code 334 <xref target="RFC4004"/>) is of type
Address and contains the HA address. The Diameter server MAY decide to assign a HA
to the MN that is in close proximity to the point of attachment (e.g., determined
by the NAS-Identifier AVP). There may be other reasons for dynamically assigning
HAs to the MN, for example to share the traffic load. </t>
</section>
<section title="MIP-Home-Agent-Host AVP">
<t>The MIP-Home-Agent-Host AVP (AVP Code 348 <xref target="RFC4004"/>) is of type
Grouped and contains the identity of the assigned HA. Both the Destination-Realm
and the Destination-Host AVP of the HA are included in the grouped AVP. The usage
of this AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an
additional level of indirection by using the DNS
infrastructure.
</t>
<t>Depending on the actual deployment and DNS configuration the
Destination-Host AVP MAY represent one or more home
agents. It is RECOMMENDED that the Destination-Host
AVP identifies exactly one HA.
</t>
</section>
<section title="MIP6-Home-Link-Prefix AVP">
<t>The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString and contains
the Mobile IPv6 home network prefix information in network byte order. The home
network prefix MUST be encoded as the 8-bit prefix length information followed by
the 128-bit field for the available home network prefix. </t>
</section>
<section title="MIP6-Feature-Vector AVP" anchor="capability">
<t>The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and contains a 64
bit flags field of supported capabilities of the NAS/ASP. Sending and receiving
the MIP6-Feature-Vector AVP with value 0 MUST be supported, although that does not
provide much guidance about specific needs of bootstrapping. </t>
<t>The NAS MAY include this AVP to indicate capabilities of the NAS/ASP to the
Diameter server. For example, the NAS may indicate that a local HA can be
provided. Similarly, the Diameter server MAY include this AVP to inform the
NAS/ASP about which of the NAS/ASP indicated capabilities are supported or
authorized by the ASA/MSA(/MSP). </t>
<t>The following capabilities are defined in this document: </t>
<t>
<list style="hanging">
<vspace blankLines="1"/>
<t hangText="MIP6_INTEGRATED (0x0000000000000001)">
<vspace blankLines="1"/>When this flag is set by the NAS then it means that
the Mobile IPv6 integrated scenario bootstrapping functionality is supported
by the NAS. When this flag is set by the Diameter server then the Mobile
IPv6 integrated scenario bootstrapping is supported by the Diameter server. </t>
<vspace blankLines="1"/>
<t hangText="LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002)">
<vspace blankLines="1"/> When this flag is set in the
request message, a local home
agent outside the home realm is requested and may be assigned
to the MN. When this flag is set by the Diameter
server in the answer message, then the assignment of local HAs is
authorized by the Diameter server.
<vspace blankLines="1"/>
A local HA may be assigned by the NAS, LAAA or
VAAA depending on the network architecture and the
deployment.
</t>
</list>
</t>
<t>The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT capability and the
MIP-Agent-Info AVP are used to assign HAs,
either a local HA (L-HA) or a home network HA (H-HA). Below
is an example of a
request message combinations as seen by the HAAA:
<artwork><![CDATA[
LOCAL-bit HA-Info Meaning
0 - ASP or [LV]AAA is not able to assign a L-HA
0 L-HA Same as above. HA-Info must be ignored
1 - ASP or [LV]AAA can/wishes to assign a L-HA
1 L-HA Same as above but ASP or [LV]AAA also
provides a hint of the assigned L-HA
]]></artwork>
</t>
<t>Then the same as above for an answer message
combinations as seen by the NAS:
<artwork><![CDATA[
LOCAL-bit HA-Info Meaning
0 - No HA allowed -> no mobility
0 H-HA L-HA is not allowed. HAAA assigns a H-HA
1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA
1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA
1 H-HA L-HA is allowed. HAAA also assigns a HA
1 H-HA L-HA is allowed. HAAA assigns a H-HA and
+ L-HA [LV]AAA also assigns also a L-HA
]]></artwork>
</t>
</section>
</section>
</section>
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<section title="Examples">
<section title="Home Agent Assignment by the NAS">
<t>In this scenario we consider the case where the NAS wishes to allocate a local HA to
the MN. The NAS will also inform the Diameter server about the HA address it has
assigned to the visiting MN (e.g., 2001:db8:1:c020::1). The Diameter-EAP-Request
message therefore has the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT
and the MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the
MIP-Home-Agent-Address AVP with the address of the proposed HA. </t>
<t>
<figure anchor="example3" title="Home Agent Assignment by NAS">
<artwork><![CDATA[
Diameter
NAS Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
]]></artwork>
</figure>
</t>
<t> Depending on the Diameter server configuration and user's subscription profile, the
Diameter server either accepts or rejects the proposal of locally HA allocated by the
NAS will be used. In our example, the Diameter server accepts the proposal and the
the MIP6-Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the
MIP6_INTEGRATED flag) is set and returned to the NAS. </t>
</section>
<section title="Home Agent Assignment by the Diameter Server">
<t>In this scenario we consider the case where the NAS supports the Diameter MIPv6
integrated scenario as defined in this document but does not offer local HA
assignment. Hence, the MIP6-Feature-Vector AVP only has the MIP6_INTEGRATED flag set.
The Diameter server allocates a HA to the mobile node and conveys the address
in the MIP-Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info AVP.
Additionally, the MIP6-Feature-Vector AVP has the MIP6_INTEGRATED flag set.</t>
<t>
<figure anchor="example2" title="Home Agent Assignment by Diameter Server">
<artwork><![CDATA[
Diameter
NAS Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1/64) |
| } |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
]]></artwork>
</figure>
</t>
</section>
<section title="Home Agent Assignment by NAS or Diameter Server">
<t>This section shows a message flow for the MIPv6 integrated scenario bootstrapping
where the NAS informs the Diameter server that it is able to locally assign a HA to
the MN. The Diameter server is able to provide a HA to the MN but also authorizes the
assignment of local HA. The Diameter server then replies to the NAS with HA related
bootstrapping information.</t>
<t>Whether the NAS/ASP then offers a locally assigned HA or the Diameter server assigned
HA to the MN is, in this example, based on the local ASP policy. </t>
<t>
<figure anchor="example1" title="Home Agent Assignment by NAS or Diameter Server">
<artwork><![CDATA[
Diameter
NAS Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
]]></artwork>
</figure>
</t>
<t>If the Diameter server does not accept locally assigned HA, the Diameter returns the
MIP6-Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it
plans to allocate for the MN.</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="AVP Occurrence Tables" anchor="nasavpoccurance">
<!--section anchor="nasavptable" title="AAR, ACommands AVP Table"-->
<t>The following table lists the additional MIPv6 bootstrapping NAS to HAAA interface
AVPs that may be present in any Diameter
application request and answer commands, where permitted by the
command ABNF.
</t>
<t>
<figure anchor="nasavptable"
title="Generic Request and Answer Commands AVP Table">
<artwork><![CDATA[
+-----------+
| Command |
|-----+-----+
Attribute Name | Req | Ans |
-------------------------------|-----+-----|
MIP6-Agent-Info | 0+ | 0+ |
MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Home-Link-Prefix | 0+ | 0+ |
+-----+-----+
]]></artwork>
</figure>
</t>
</section>
<!--section title="MIPv6 Bootstrapping NAS to HAAA Interface AVPs">
<t>This section defines AVPs that are specific to Diameter MIPv6 bootstrapping NAS to HAAA
interface and MAY be included in the Diameter EAP <xref target="RFC4072"/> and the
NASREQ <xref target="RFC4005"/> application messages. The Diameter AVP rules are defined
in the Diameter Base <xref target="RFC3588"/>, Section 4. These AVP rules are observed
in AVPs defined in this section. </t>
<t>The following table describes the Diameter AVPs, their AVP Code values, types, possible
flag values, and whether the AVP MAY be encrypted. The Diameter base <xref
target="RFC3588"/> specifies the AVP Flag rules for AVPs in Section 4.5. <figure
anchor="flagstable" title="AVP Flag Rules Table">
<artwork><![CDATA[
+---------------------+
| AVP Flag rules |
+----+-----+----+-----+----+
AVP Section | | |SHLD|MUST | |
Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr|
------------------------------------------+----+-----+----+-----+----+
MIP6-Agent-Info TBD 4.7.1 Grouped | | P | | V,M | Y |
MIP-Home-Agent- | | | | | |
Address 334 4.7.2 Address | | P | | V,M | Y |
MIP-Home-Agent- | | | | | |
Host 348 4.7.3 Grouped | | P | | V,M | Y |
MIP6-Feature- | | | | | |
Vector TBD 4.7.5 Unsigned64 | | P | | V,M | Y |
MIP6-Home-Link- TBD 4.7.4 OctetString| | P | | V,M | Y |
Prefix | | | | | |
------------------------------------------+----+-----+----+-----+----+
]]></artwork>
</figure></t>
</section-->
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<section title="IANA Considerations">
<section title="Registration of new AVPs">
<t>This specification defines the following new AVPs: <figure>
<artwork><![CDATA[
MIP6-Agent-Info is set to TBD
MIP6-Feature-Vector is set to TBD
MIP6-Home-Link-Prefix is set to TBD
]]></artwork>
</figure></t>
</section>
<section title="New Registry: Mobility Capability">
<t>IANA is requested to create a new registry for the Mobility Capability as described
in <xref target="capability"/>. <figure>
<artwork><![CDATA[
Token | Value | Description
----------------------------------+----------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD]
Available for Assignment via IANA | 2^x |
]]></artwork>
</figure> Allocation rule: Only numeric values that are 2^x (power of two) are
allowed based on the allocation policy described below. </t>
<t> Following the policies outlined in <xref target="RFC3775"/> new values with a
description of their semantic for usage with the MIP6-Feature-Vector AVP together
with a Token will be assigned after Expert Review initiated by the O&M Area
Directors in consultation with the DIME working group chairs or the working group
chairs of a designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the O&M Area
Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on
expert approval it is possible to delete entries from the registry. </t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t>The security considerations for the Diameter interaction required to accomplish the
integrated scenario are described in <xref
target="I-D.ietf-mip6-bootstrapping-integrated-dhc"/>. Additionally, the security
considerations of the Diameter base protocol <xref target="RFC3588"/>, Diameter NASREQ
application <xref target="RFC4005"/> / Diameter EAP <xref target="RFC4072"/> application
(with respect to network access authentication and the transport of keying material) are
applicable to this document. This document does not introduce new security
vulnerabilities. </t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>This document is heavily based on the ongoing work for RADIUS MIPv6 interaction. Hence,
credits go to respective authors for their work with draft-ietf-mip6-radius.
Furthermore, the author would like to thank the authors of
draft-le-aaa-diameter-mobileipv6 (Franck Le, Basavaraj Patil, Charles E. Perkins,
Stefano Faccin) for their work in context of MIPv6 Diameter interworking. Their work
influenced this document. Jouni Korhonen would like to thank Academy of Finland and
TEKES MERCoNe Project for providing funding to work on this document. Julien Bournelle
would like to thank GET/INT since he began to work on this document while he was in
their employ. Authors would also like to acknowledge Raymond Hsu for his valuable
feedback on local HA assignment and Wolfgang Fritsche for his thorough review. Finally,
we would like to Domagoj Premec for his review comments.</t>
<t>We would like to thank Alper Yegin, Robert Marks, David Frascone for their comments at
the second WGLC. </t>
</section>
<!-- ====================================================================== -->
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC3588; &RFC3775; &RFC4072;
&RFC4004; &RFC4005; &RFC2119; </references>
<references title="Informative References"> &I-D.ietf-mip6-bootstrapping-integrated-dhc;
&I-D.ietf-mext-aaa-ha-goals; &RFC5026; &RFC4640; &RFC3753; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:24 |