One document matched: draft-ietf-dime-mip6-split-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.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 RFC4283 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml'>
<!ENTITY RFC4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY RFC4640 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4640.xml'>
<!ENTITY RFC4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY I-D.ietf-mip6-rfc4285bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-rfc4285bis.xml'>
<!ENTITY I-D.ietf-mip6-aaa-ha-goals PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-aaa-ha-goals.xml'>
<!ENTITY I-D.ietf-mip6-bootstrapping-split PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-bootstrapping-split.xml'>
<!ENTITY I-D.ietf-dime-qos-attributes PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-qos-attributes.xml'>
<!ENTITY I-D.ietf-dime-app-design-guide PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-app-design-guide.xml'>
<!ENTITY I-D.ietf-dime-mip6-integrated PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-mip6-integrated.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'>
]>
<rfc category="std" ipr="full3978" docName="draft-ietf-dime-mip6-split-05.txt">
<front>
<title abbrev="Diameter MIP6: HA-to-AAAH Support">Diameter Mobile IPv6: Support for Home Agent
to Diameter Server Interaction</title>
<author role="editor" 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 initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<author fullname="Julien Bournelle" surname="Bournelle" initials="J.">
<organization>France Telecom R&D </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="G." surname="Giaretta" fullname="Gerardo Giaretta">
<organization abbrev="Qualcomm">Qualcomm</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>gerardo.giaretta@gmail.com</email>
</address>
</author>
<author initials="M." surname="Nakhjiri" fullname="Madjid Nakhjiri">
<organization>Motorola</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>USA</country>
</postal>
<email>madjid.nakhjiri@motorola.com</email>
</address>
</author>
<date year="2007"/>
<area>Operations and Management Area</area>
<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an
interaction between the Home Agent and the Diameter server of the Mobile Service Provider
(MSP). This document specifies the interaction between a Mobile IP Home Agent and the
Diameter server.</t>
<t>Several different mechanisms for authenticating a Mobile Node are supported. The usage of
the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the
Extensible Authentication Protocol (EAP), certificates and pre-shared secrets in IKEv2 to be
used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In
addition to authentication authorization, the configuration of Mobile IPv6 specific
parameters and accounting is specified in this document.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>Performing the Mobile IPv6 protocol <xref target="RFC3775"/>, requires the Mobile Node (MN)
to own a Home Address (HoA) and assignment of a Home Agent (HA) to the MN. The MN needs to
register with the HA in order facilitate its reachability and mobility, when away from home.
The registration process itself requires establishment of IPsec security associations (SA)
and cryptographic material between the MN and HA. Providing the collection of home address,
HA address and keying material is generally referred to as the Mobile IPv6 bootstrapping
problem <xref target="RFC4640"/>. The purpose of this specification is to provide Diameter
support for the interaction between the HA and the AAA server, as it is required for
bootstrapping in the split scenario <xref target="I-D.ietf-mip6-bootstrapping-split"/> and
in the integrated scenario <xref target="I-D.ietf-mip6-bootstrapping-integrated-dhc"/> in a
manner that satisfies the requirements defined in <xref target="I-D.ietf-mip6-aaa-ha-goals"
/>.</t>
<t>From an operator (mobility service provider, MSP) perspective, it is important to verify
that the MN is authenticated and authorized to utilize Mobile IPv6 service and that such
services are accounted for. Only when the MN is authenticated and authorized, the MSP allows
the boostrapping of Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6
service requests, the HA, participates in the authentication of the MN to verify the MN's
identity. The HA also participates in the Mobile IPv6 authorization process involving the
Diameter infrastrucure. The HA due to its role in traffic forwarding, also may also perform
accounting for the Mobile IPv6 service provided to the MN.</t>
<t>This document enables the following functionality:</t>
<t>
<list style="hanging">
<t hangText="Authentication:">Asserting or helping in asserting of the correctness of the
MN identity. As a Diameter client supporting the new Diameter Mobile IPv6 application,
the HA may need to support more than one authentication type depending on the
environment. Although the authentication is performed by the AAA server there is an
impact for the HA as different set of command codes are needed for the respective
authentication procedures. <vspace blankLines="1"/>
</t>
<t hangText="Authorization:">The HA must verify that the user is authorized to use the
Mobile IPv6 service using the assistance of the MSP Diameter servers. This is
accomplised through the use of new Diameter commands specifically designed for
performing Mobile IPv6 authorization decisions. This document defines these commands and
requires the HA to support them and to participate in this authorization
signaling.<vspace blankLines="1"/>
</t>
<t hangText="Accounting:"> For accounting purposes and capacity planning, it is required
of the HA to provide accounting report to the Diameter infrastructure and thus to
support the related Diameter accounting procedures.<vspace blankLines="1"/>
</t>
</list>
</t>
<t>
<xref target="arch-mip6"/> depicts the architecture.</t>
<figure anchor="arch-mip6" title="Architecture Overview">
<artwork><![CDATA[
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | Diameter MIPv6
Protocol | HA<->AAA Server
Support | Interaction
| (this document)
v
+---------+ +--------------+
| Mobile | Front-End Protocol |Home Agent / |
| Node |<--------------------------|Diemter Client|
+---------+ IKEv2 or RFC 4285 +--------------+
]]></artwork>
</figure>
<t>Mobile IPv6 signaling between the MN and the HA can protected using two different
mechanisms, namely using IPsec and via the MIPv6 Auth. Protocol. Note that the actual
mechanism to protect the MIPv6 signaling messages is only indirectly relevant to this
document. The important aspect is, however, that for these two approaches several different
authentication and key exchange solutions are available. To establish IPsec security
associations for protection of Mobile IPv6 signaling messages IKEv2 is used, see <xref
target="RFC4877"/>. IKEv2 supports EAP-based authentication, certificates and pre-shared
secrets. For protecting using the MIPv6 Auth. Protocol <xref
target="I-D.ietf-mip6-rfc4285bis"/> a mechanism has been designed that is very similar to
the one used by Mobile IPv4. </t>
<t> The ability to use different credentials has an impact on the interaction between the HA
(acting as a Diameter client) and the Diameter Server. For that reason this document
illustrates the usage of these authentication mechanisms with different subsections for
<list style="symbols">
<t>IKEv2 usage with EAP</t>
<t>IKEv2 usage with certificates and pre-shared secrets</t>
<t>MIPv6 Auth. Protocol</t>
</list>
</t>
<t>For accounting of Mobile IPv6 services provided to the MN, this specification uses the
accounting application defined in <xref target="RFC3588"/>.</t>
</section>
<!-- ====================================================================== -->
<section anchor="terminology" title="Terminology">
<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 RFC 2119 <xref target="RFC2119"/>. </t>
<t>The MIPv6 bootstrapping terminology is taken from <xref target="RFC4640"/>.</t>
</section>
<!-- ====================================================================== -->
<section title="Advertising Application Support">
<t>Diameter nodes conforming to this specification MUST advertise support by including the
Diameter Mobile IPv6 Application ID value of [TO BE ASSIGNED BY IANA] in the
Auth-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer command <xref target="RFC3588"/>. The Acct-Application-id AVP
needs to include the Diameter Base Accounting Application ID value of 3 (to support the
split accounting model <xref target="I-D.ietf-dime-app-design-guide"/>). </t>
</section>
<!-- ====================================================================== -->
<section title="Protocol Description">
<section title="Support for Mobile IPv6 with IKEv2 and EAP">
<t>The use of IKEv2 with EAP between the MN and the HA allows the AAA to authenticate the
MN. When EAP is used with IKEv2, the Diameter EAP application, as defined in <xref
target="RFC4072"/>, is re-used. EAP methods that do not establish a shared key SHOULD
NOT be used, as they are subject to a number of man-in-the-middle attacks as stated in
Section 2.16 and Section 5 of RFC 4306 <xref target="RFC4306"/>. AVPs specific to Mobile
IPv6 bootstrapping are added to the EAP application commands. </t>
<t>
<xref target="fig-ikev2-diameter-msg"/> shows the message flow involved during the
authentication phase when EAP is used.</t>
<figure anchor="fig-ikev2-diameter-msg" title="Mobile IPv6 with IKEv2 and EAP">
<artwork><| |
|<------------------------------->| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | |
|-------------------------------->| DER (EAP-Response) (4) |
| |------------------------->|
| | |
| | DEA (EAP-Request) (5) |
| HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
| | |
| | DEA (EAP-Request) |
| HDR, SK{EAP-Request} |<-------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP-Response} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
| ... | ... |
| | |
| | DEA (EAP-Success) |
| |<-------------------------|
| HDR, SK{EAP-Success} | |
|<------------------------------- | |
| | |
| HDR, SK{AUTH} | |
|-------------------------------> | |
| | |
| HDR, SK{AUTH, [CP(CFG_REPLY,] | |
| SAr2, TSi, TSr} | |
|<------------------------------- | |
| | |
]]></artwork>
</figure>
<t>The MN and the HA start the interaction with an IKE_SA_INIT exchange. In this phase
cryptographic algorithms are negotiated, nonces and Diffie-Hellman parameters are
exchanged. Message (3) starts the IKE_AUTH phase. This second phase authenticates the
previous messages, exchanges identities and certificates and establishes the first
CHILD_SA. It is used to mutually authenticate the MN (acting as an IKEv2 Initiator) and
the HA (acting as an IKEv2 Responder). The identity of the user/MN is provided in the IDi
field. The MN indicates its willingness to be authenticated via EAP by omitting the AUTH
field in message (3) (see Section 2.16 of <xref target="RFC4306"/>). </t>
<t>As part of the authentication process, the MN MAY request a Home-Address, a Home Prefix
or suggests one, see <xref target="RFC4877"/>, using a CFG_REQUEST payload in the message
(3).</t>
<t>The HA extracts the IDi field from the message (3) and sends a Diameter-EAP-Request (DER)
message (4) towards the authenticating Diameter server. The EAP-Payload AVP contains a
EAP-Response/Identity with the identity extracted from the IDi field. </t>
<t>This message is routed to the MNs Diameter server/EAP server. The Diameter server selects
the EAP method and replies with the DEA Message. Depending on the type of EAP method
chosen, a number of DER and DEA messages carry the method specific exchanges between the
MN and the Diameter server/EAP server. </t>
<t>At the end of the EAP authentication phase, the Diameter server indicates the result of
the authentication in the Result-Code AVP and provides the corresponding EAP packet (EAP
Success or EAP Failure). The last IKEv2 message sent by the HA contains the Home Address
or the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is necessary to setup
IPsec SAs for Mobile IPv6 signalling.</t>
<t>In some deployment scenario, the HA may also acts as a IKEv2 Responder for IPsec VPN
access. A problem in this case is that the IKEv2 responder may not know if IKEv2 is used
for MIP6 service or for IPsec VPN access. A network operator needs to be aware of this
limitation.</t>
</section>
<section title="Support for Mobile IPv6 with IKEv2 and Certificates">
<t>When IKEv2 is used with certificate-based authentication, the Diameter NASREQ application
<xref target="RFC4005"/> is used to authorize the MN for the Mobile IPv6 service. The
IDi payload extracted from the IKE_AUTH message MUST correspond to the identity in the
MN's certificate. This identity is then used by the Home Agent to populate the User-Name
AVP in the succeeding AA-Request message. Further PKI-related procedures such as
certificate revocation checking are out of scope of this document. </t>
</section>
<section title="Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets">
<t>When IKEv2 is used with PSK-based initiator authentication, the Diameter NASREQ
application <xref target="RFC4005"/> isused to authorize the MN for the Mobile IPv6
service. The IDi payload extracted from the IKE_AUTH message has to contain an identity
that is meaningful for the Diameter infrastructure, such as a Network Access Identifier
(NAI), and is then used by the Home Agent to populate the User-Name AVP is the succeeding
AA-Request message. </t>
</section>
<section title="Support for the Mobile IPv6 Authentication Protocol">
<t>
<xref target="rfc4285-flow"/> describes the sequence of messages sent and received between
the MN, the HA and the Diameter server during the registration when MIPv6 Auth. Protocol
is used. Binding Update (BU) and Binding Acknowledgement (BA) messages are used in the
registration process. This exchange triggers the Diameter interaction. </t>
<t>According to <xref target="I-D.ietf-mip6-rfc4285bis"/> the MN uses the Mobile Node
Identifier Option, specifically the MN-NAI mobility option (as defined in <xref
target="RFC4283"/>) to identify itself. </t>
<!-- <t>The MN may use the Mobility Message Replay Protection Option for additional replay
protection.</t>
-->
<t> The BU initiates a MIP6-Request-Message to the Diameter server and the corresponding
response is carried in a MIP6-Answer-Message. The Home Agent also provides the assigned
Home Address to the Diameter server in the MIP-Mobile-Node-Address AVP. </t>
<t>
<figure anchor="rfc4285-flow" title="MIPv6 Bootstrapping using the MIPv6 Auth. Protocol">
<artwork><![CDATA[
Mobile Home Diameter
Node Agent Server
| | |
| | |
| Binding Update |MIP6-Request-Message |
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | |
| Binding Acknowledgement |MIP6-Answer-Message |
|<------------------------------------|<--------------------|
| (Mobile Node Identifier Option | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
]]></artwork>
</figure>
</t>
</section>
<section title="Mobile IPv6 Session Management">
<t>The Diameter server may maintain state or may be stateless. This is indicated in the
Auth-Session-State AVP (or its absence). The HA MUST support the Authorization Session
State Machine defined in <xref target="RFC3588"/>. Moreover, the following four commands
may be exchanged between the HA and the Diameter server. </t>
<section title="Session-Termination-Request Command">
<t>The Session-Termination-Request (STR) message <xref target="RFC3588"/> is sent by the
HA to inform the Diameter server that an authorized session is being terminated. </t>
</section>
<section title="Session-Termination-Answer Command">
<t>The Session-Termination-Answer (STA) message <xref target="RFC3588"/> is sent by the
Diameter server to acknowledge the notification that the session has been
terminated.</t>
</section>
<section title="Abort-Session-Request Command">
<t>The Abort-Session-Request (ASR) message <xref target="RFC3588"/> is sent by the
Diameter server to terminates the session. This fulfills one of the requirement
described in <xref target="I-D.ietf-mip6-aaa-ha-goals"/>.</t>
</section>
<section title="Abort-Session-Answer Command">
<t>The Abort-Session-Answer (ASA) message <xref target="RFC3588"/> is sent by the Home
Agent in response to an ASR message.</t>
</section>
</section>
<section title="Accounting for Mobile IPv6 services">
<t>The HA MUST be able act as a Diameter client collecting accounting records needed for
service control and charging. The HA MUST support the accounting procedures (specifically
the command codes mentioned below) and the Accounting Session State Machine as defined in
<xref target="RFC3588"/>. The command codes, exchanged between the HA and Diameter
server for accounting purposes, are provided in the following subsections.</t>
<t>The Diameter application design guideline <xref target="I-D.ietf-dime-app-design-guide"/>
defines two separate models for accounting:</t>
<t>
<list style="hanging">
<t hangText="Split accounting model:"><vspace blankLines="1"/> According to this model,
the accounting messages use the Diameter base accounting application ID (value of 3).
Since accounting is treated as an independent application, accounting commands may be
routed separately from the rest of application messages and thus the accounting
messages generally end up in a central accounting server. Since Diameter Mobile IPv6
application does not define its own unique accounting commands, this is the prefered
choice, since it permits use of centralized accounting for several
applications.<vspace blankLines="1"/></t>
<t hangText="Coupled accounting model:"><vspace blankLines="1"/> In this model, the
accounting messages will use the application ID of the Mobile IPv6 application. This
means that accounting messages will be routed like any other Mobile IPv6 application
messages. This requires the Diameter server in charge of Mobile IPv6 application to
handle the accounting records (e.g., sends them to a proper accounting server).</t>
</list>
</t>
<t>As mentioned above, the prefered choice is to use the split accounting model and thus to
choose Diameter base accounting application ID (value of 3) for accounting messages.</t>
<section title="Accounting-Request Command">
<t>The Accounting-Request command <xref target="RFC3588"/> is sent by the HA to the
Diameter server to exchange accounting information regarding the MN with the Diameter
server.</t>
</section>
<section title="Accounting-Answer Command">
<t>The Accounting-Answer command <xref target="RFC3588"/> is sent by the Diameter server
to the HA to acknowledge receiving an Accounting-Request.</t>
</section>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="Command-Code-Values" title="Command Codes">
<section title="Command Code for Mobile IPv6 with IKEv2 and EAP">
<t>For usage of Mobile IPv6 with IKEv2 and EAP this document re-uses the Diameter EAP
application <xref target="RFC4072"/> commands. The following commands are used to carry
MIPv6 related bootstrapping AVPs.</t>
<t>
<figure anchor="cmd-eap" title="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>
<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 HA to the Diameter server to initiate a Mobile IPv6 service authentication and
authorization procedure. The DER message format is the same as defined in <xref
target="RFC4072"/>. The Application-ID field of the Diameter Header MUST be set to the
Diameter Mobile IPv6 Application ID [TO BE ASSIGNED TO IANA].</t>
<t>
<figure>
<artwork><![CDATA[
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ User-Name ]
{ EAP-Payload }
[ MIP6-Feature-Vector ]
[ MIP-Home-Agent-Address ]
{ MIP-Mobile-Node-Address }
...
* [ AVP ]
]]></artwork>
</figure>
</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 Mobile IPv6
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"/>. The
Application-Id field in the Diameter header MUST be set to the Diameter Mobile IPv6
Application-Id [TO BE ASSIGNED BY IANA].</t>
<t>
<figure>
<artwork><![CDATA[
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
{ EAP-Payload }
[ Authorization-Lifetime ]
[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
...
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
</section>
<section
title="Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK-based Authentication">
<t>This document re-uses the Diameter NASREQ application commands. The following commands
are used to carry MIPv6 related bootstrapping AVPs. </t>
<t>
<figure anchor="cmd-nas" title="Command Codes">
<artwork><![CDATA[
Command-Name Abbrev. Code Reference Application
------------------------------------------------------------------
AA-Request AAR 265 RFC 4005 NASREQ
AA-Answer AAA 265 RFC 4005 NASREQ
]]></artwork>
</figure>
</t>
<section title="AA-Request (AAR)">
<t> The AA-Request (AAR) message <xref target="RFC4005"/>, indicated by the Command-Code
field set to 265 and the 'R' bit set in the Command Flags field, is sent by the HA to
the Diameter server to initiate a Mobile IPv6 service authentication and authorization
procedure. The AAR message format is the same as defined in <xref target="RFC4005"/>.
The Application-ID field of the Diameter Header MUST be set to the Diameter Mobile IPv6
Application ID [TO BE ASSIGNED TO IANA].</t>
<t>
<figure>
<artwork><![CDATA[
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ User-Name ]
[ MIP6-Feature-Vector ]
[ MIP-Home-Agent-Address ]
{ MIP-Mobile-Node-Address }
...
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
<section title="AA-Answer (AAA)">
<t>The AA-Answer (AAA) message defined in <xref target="RFC4005"/>, 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 message (AAR). If the Mobile IPv6 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"/>. The
Application-Id field in the Diameter header MUST be set to the Diameter Mobile IPv6
Application-Id [TO BE ASSIGNED BY IANA].</t>
<t>
<figure>
<artwork><![CDATA[
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Authorization-Lifetime ]
[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
...
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Command Codes for MIPv6 Auth. Protocol Support">
<t> This section defines the commands that are used for support with the MIPv6 Auth.
Protocol.</t>
<t>
<figure title="Command Codes">
<artwork><![CDATA[
Command-Name Abbreviation Code Section
------------------------------------------------------------------
MIP6-Request-Message MRM TBD Section 6.2.1
MIP6-Answer-Message MAM TBD Section 6.2.2
]]></artwork>
</figure>
</t>
<section title="MIP6-Request-Message">
<t>The MIP6-Request-Message (MRM), indicated by the Command-Code field set to TBD and the
'R' bit set in the Command Flags field, is sent by the HA, acting as a Diameter client,
in order to request the authentication and authorization of a MN. The HA uses
information found in the Binding Update to construct the following AVPs, to be included
as part of the MRM:</t>
<t>
<list style="symbols">
<t>Home Address (MIP-Mobile-Node-Address AVP)</t>
<t>Mobile Node NAI (User-Name AVP <xref target="RFC3588"/>) </t>
<t>MN-AAA Authentication Option (MIP-MN-AAA-Auth AVP)</t>
<t>Care-of Address (MIP-Careof-Address AVP)</t>
<t>Mobility message replay protection Option using
timestamps (MIP-Timestamp AVP)</t>
</list>
</t>
<!-- JiK t>If the MN's home address is zero, the HA MUST NOT include a MIP-Mobile-Node-Address
AVP.</t>
<t> If the MN's home address is all ones, the HA MUST include a MIP-Mobile-Node-Address
AVP, set to all ones.</t -->
<t>The message format is shown below.</t>
<t>
<figure>
<artwork><![CDATA[
<MIP6-Request-Message> ::= < Diameter Header: XXX, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ MIP6-Feature-Vector ]
{ MIP-MN-AAA-SPI }
{ MIP-Mobile-Node-Address ]
{ MIP-Home-Agent-Address }
{ MIP-Careof-Address }
{ MIP-Authenticator }
{ MIP-MAC-Mobility-Data }
[ MIP-Timestamp ]
[ QoS-Capability ]
* [ QoS-Resources ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
<section title="MIP6-Answer-Message">
<t> The MIP6-Answer-Message (MAM) message, indicated by the Command-Code field set to TBD
and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server in
response to the MIP6-Request-Message message. The User-Name MAY be included in the MAM
if it is present in the MRM. The Result-Code AVP MAY contain one of the values defined
in <xref target="result"/>, in addition to the values defined in RFC 3588 <xref
target="RFC3588"/>.</t>
<t>An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the
MIP-Mobile-Node-Address AVP.</t>
<t> The message format is shown below.</t>
<t>
<figure>
<artwork><![CDATA[
<MIP6-Answer-Message> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP6-Feature-Vector ]
[ MIP-Home-Agent-Address ]
{ MIP-Mobile-Node-Address }
{ MIP-Session-Key }
{ MIP-MSA-Lifetime }
{ MIP-MN-to-HA-MSA }
* [ QoS-Resources ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
]]></artwork>
</figure>
</t>
<t>The QoS-Resources AVP is defined in <xref target="I-D.ietf-dime-qos-attributes"/>. </t>
</section>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="avps" title="AVPs">
<t>To provide support for RFC 4285 <xref target="I-D.ietf-mip6-rfc4285bis"/> and for RFC 4877
<xref target="RFC4877"/> the AVPs in the following subsections are needed. RFC 3588, RFC
4004 and RFC 4005 defined AVPs are reused whenever possible without violating the existing
semantics of those AVPs. </t>
<t>
<figure title="AVPs for Mobile IPv6 with IKEv2">
<artwork><![CDATA[
+--------------------------+
| AVP Flag rules |
+----+-----+----+-----+----+
AVP Defined | | |SHLD| MUST|MAY |
Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr|
+-----------------------------------------+----+-----+----+-----+----+
|MIP6-Feature- TBD Note 1 Unsigned64 | | P | | M,V | Y |
| Vector | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Mobile- | | M,P | | V | Y |
|Node-Address 334 RFC4004 Address | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Home- 334 RFC4004 Address | | M,P | | V | Y |
| Agent-Address | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
]]></artwork>
</figure>
</t>
<t>Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of <xref
target="I-D.ietf-dime-mip6-integrated"/>.</t>
<t>
<figure title="AVPs for the Mobile IPv6 Authentication Protocol">
<artwork><![CDATA[
+--------------------------+
| AVP Flag rules |
+----+-----+----+-----+----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
+-----------------------------------------+----+-----+----+-----+----+
|MIP6-Feature- TBD Note 1 Unsigned64 | | P | | M,V | Y |
| Vector | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Mobile- 333 RFC4004 Address | | M,P | | V | Y |
| Node-Address | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Home- 334 RFC4004 Address | | M,P | | V | Y |
| Agent-Address | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | M | P | | V | Y |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Careof- TBD 5.4.5 Address | M | P | | V | Y |
| Address | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP- TBD 5.4.6 OctetString| M | P | | V | Y |
| Authenticator | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-MAC- TBD 5.4.7 OctetString| M | P | | V | Y |
| Mobility-Data | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Timestamp TBD TBD Time | | M,P | | V | Y |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-Session-Key 343 RFC4004 OctetString| M | P | | V | Y |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y |
| Lifetime | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|MIP-MN-to- 331 RFC4004 Grouped | M | P | | V | Y |
| HA-MSA | | | | | |
+-----------------------------------------+----+-----+----+-----+----+
|QoS-Capability TBD Note 2 Groupe | | M,P | | V | Y |
+-----------------------------------------+----+-----+----+-----+----+
|QoS-Resources TBD Note 2 Grouped | | M,P | | V | Y |
+-----------------------------------------+----+-----+----+-----+----+
]]></artwork>
</figure>
</t>
<t>Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of <xref
target="I-D.ietf-dime-mip6-integrated"/>.
</t>
<t>Note 2: The QoS-Capability and QoS-Resource AVPs are defined
in Sections 4.1 and 4.3 of <xref
target="I-D.ietf-dime-qos-attributes"/>.
</t>
<section title="User-Name AVP">
<t>The User-Name AVP (AVP Code 2) is of type UTF8String and contains an NAI extracted from
the MN-NAI mobility option included in the received BU message. Alternatively, the NAI can
be extracted from the IKEv2 IDi payload included in the IKE_SA_INIT message. </t>
</section>
<section title="MIP-MN-AAA-SPI AVP">
<t>The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and contains an SPI code
extracted from the Mobility Message Authentication Option included in the received BU
message. </t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-Mobile-Node-Address AVP">
<t>The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the Home
Agent assigned IPv6 Home Address of the Mobile Node. </t>
<t> If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address (0::0) in a request
message, then the Home Agent expects the Diameter server to assign the Home Address in a
subsequent reply message. In case the Diameter server assigns only a prefix to the Mobile
Node the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address are set to
zero.</t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-Home-Agent-Address AVP">
<t>The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and contains the IPv6
address of the Home Agent. This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-Careof-Address AVP">
<t>The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and contains the IPv6
Care-of Address of the Mobile Node. The Home Agent extracts this IP address from the
received BU message. </t>
</section>
<section title="MIP-Authenticator AVP">
<t>The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and contains the
Authenticator Data from the received BU message. The Home Agent extracts this data from
the MN-AAA Mobility Message Authentication Option included in the received BU message.
</t>
</section>
<section title="MIP-MAC-Mobility-Data AVP">
<t>The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString and contains the
calculated MAC_Mobility_Data, as defined in <xref target="I-D.ietf-mip6-rfc4285bis"/>.
</t>
</section>
<section title="MIP-Session-Key AVP" anchor="mip-session-key">
<t>The AVP (AVP Code 343) is of type OctetString and contains the MN-HA shared secret (i.e.,
the session key) for the associated Mobile IPv6 MH-HA authentication option. When the
Diameter server computes the session key it is placed in this AVP. </t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-MSA-Lifetime AVP">
<t>The AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in
seconds) for which the session key (see <xref target="mip-session-key"/>) or nonce (see
<xref target="mip-nonce"/>) is valid. The associated session key or nonce MUST NOT be
used if the lifetime has expired. </t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<!--section title="MIP-HA-to-MN-MSA AVP">
<t> The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and contains the HA-MN
session key. The AVP's field has the following ABNF grammar. </t>
<t>
<figure>
<artwork><![CDATA[
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
]]></artwork>
</figure>
</t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section-->
<section title="MIP-MN-to-HA-MSA AVP">
<!-- grouped -->
<t>The AVP (AVP Code 331) is of type Grouped and contains the session related information
for use with the MIPv6 Auth. Protocol.</t>
<t>
<figure>
<artwork><![CDATA[
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
]]></artwork>
</figure>
</t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-Algorithm-Type AVP">
<t>The AVP (AVP Code 345) is of type Enumerated and contains Algorithm identifier for the
associated Mobile IPv6 MN-HA Authentication Option. The Diameter server selects the
algorithm type. Existing algorithm types are defined in RFC 4004 that also fulfill current
RFC 4285 requirements. This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP-Replay-Mode AVP">
<t>The AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent
for authenticating the mobile node. The replay modes, defined in RFC 4004 <xref
target="RFC4004"/>, are supported. This AVP is re-used from <xref target="RFC4004"
/>.</t>
</section>
<section title="MIP-nonce AVP" anchor="mip-nonce">
<t>The AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the Mobile
Node. This AVP is re-used from <xref target="RFC4004"/>. At the time of writing the MIPv6
Auth. Protocol does not require use of nonces for replay protection between the MN and the
Diameter server. Thus, the Home Agent is allowed to ignore the returned MIP-Nonce AVP.
</t>
</section>
<section title="MIP6-Feature-Vector AVP">
<t>This AVP is defined in <xref target="I-D.ietf-dime-mip6-integrated"/>. </t>
</section>
<section title="MIP-Timestamp AVP">
<t>The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain the timestamp value
from the Mobility message replay protection option, defined in <xref
target="I-D.ietf-mip6-rfc4285bis"/>. The Home Agent extracts this value from the
received BU message, if available.</t>
<t>The support for replay protection is an optional feature in <xref
target="I-D.ietf-mip6-rfc4285bis"/>. When the Diameter server checks the timestamp
provided by the MN via the HA and recognizes a clock-drift (outside a locally defined
replay protection window) then it MUST initiate the re-synchronization procedure by
returning a MIP6-Answer-Message with Result-Code set to MIP6-TIMESTAMP-MISMATCH and
attaches the MIP-Timestamp AVP including it's current time back to the HA. </t>
</section>
<section title="QoS-Capability AVP">
<t>The QoS-Capability AVP is defined in <xref target="I-D.ietf-dime-qos-attributes"/> and
contains a list of supported Quality of Service profiles.</t>
</section>
<section title="QoS-Resources AVP">
<t>The QoS-Resources AVP is defined in <xref target="I-D.ietf-dime-qos-attributes"/> and
provides QoS and packet filtering capabilities. </t>
</section>
<!-- section title="Event-Timestamp AVP">
<t> The Event-Timestamp (AVP Code 55) is of type Time and may be included in an
Accounting-Request message to record the time at which this event occurred on the mobility
agent, in seconds since January 1, 1970, 00:00 UTC. This AVP is re-used from <xref
target="RFC4004"/>.</t>
</section -->
<section anchor="accounting" title="Accounting AVPs">
<t>This document reuses the accounting AVPs defined in Diameter Mobile IPv4 application
<xref target="RFC4004"/>, namely:</t>
<t>
<list style="hanging">
<t hangText="Accounting-Input-Octets:"><vspace blankLines="1"/> Number of octets in IP
packets received from the user<vspace blankLines="1"/></t>
<t hangText="Accounting-Output-Octets:"><vspace blankLines="1"/> Number of octets in IP
packets sent by the user<vspace blankLines="1"/></t>
<t hangText="Accounting-Input-Packets:"><vspace blankLines="1"/>Number of IP packets
received from the user<vspace blankLines="1"/></t>
<t hangText="Accounting-Output-Packets:"><vspace blankLines="1"/> Number of IP packets
sent by the user.</t>
</list>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="result" title="Result-Code AVP Values">
<t>This section defines new Result-Code <xref target="RFC3588"/> values that MUST be supported
by all Diameter implementations that conform to this specification.</t>
<section title="Transient Failures">
<t> Errors in the transient failures category are used to inform a peer that the request
could not be satisfied at the time it was received, but that it may be able to satisfy the
request in the future. </t>
<t>
<list style="hanging">
<t hangText="MIP6-TIMESTAMP-MISMATCH TBD"><vspace blankLines="1"/> This error code is
used by the home agent to indicate to the HA that the timestamp value provided as part
of the MN-AAA option has an inacceptable clock-drift. </t>
</list>
</t>
</section>
<section title="Permanent Failures">
<t>Errors that fall within the permanent failures category are used to inform the peer that
the request failed and SHOULD NOT be attempted again. </t>
<t>
<list style="hanging">
<t hangText="DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION TBD"><vspace
blankLines="1"/> This error is used by the Diameter server to inform the peer that
the requested Mobile IPv6 session keys could not be delivered via a security
association.</t>
</list>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="AVP Occurence Tables">
<t>The following tables present the AVPs defined in this document and their occurrences in
Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not
represented in this table.</t>
<t>The table uses the following symbols:</t>
<t>
<list style="hanging">
<t hangText="0:"><vspace blankLines="1"/>The AVP MUST NOT be present in the
message.<vspace blankLines="1"/></t>
<t hangText="0+:"><vspace blankLines="1"/>Zero or more instances of the AVP MAY be present
in the message.<vspace blankLines="1"/></t>
<t hangText="0-1:"><vspace blankLines="1"/>Zero or one instance of the AVP MAY be present
in the message.<vspace blankLines="1"/></t>
<t hangText="1:"><vspace blankLines="1"/>One instance of the AVP MUST be present in the
message. </t>
</list>
</t>
<section title="AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table">
<t>
<figure>
<artwork><![CDATA[
+-----------------------------------+
| Command-Code |
|-----+-----+-----+-----+-----+-----+
AVP Name | AAR | AAA | DER | DEA | MRM | MAM |
-------------------------------|-----+-----|-----+-----+-----+-----+
MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 | 1 | 0-1 | 1 | 0-1 |
MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 1 | 0 |
MIP-Home-Agent-Address | 0-1 | 0 | 0-1 | 0 | 1 | 0 |
MIP-Careof-Address | 0 | 0 | 0 | 0 | 1 | 0 |
MIP-Authenticator | 0 | 0 | 0 | 0 | 1 | 0 |
MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 1 | 0 |
MIP-Session-Key | 0 | 0 | 0 | 0 | 0 | 1 |
MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 |
MIP-MN-to-HA-MSA | 0 | 0 | 0 | 0 | 0 | 1 |
MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 |
QoS-Resources (1) | 0 | 0 | 0 | 0 | *0 | *0 |
QoS-Capability (1) | 0 | 0 | 0 | 0 | 0-1 | 0 |
+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
</t>
<t>Note (1): The QoS-Capability and QoS-Resources AVPs usage with Diameter EAP and Diameter NASREQ is
already defined in <xref target="I-D.ietf-dime-qos-attributes"/>.</t>
</section>
<section title="Accounting AVP Table">
<t> The table in this section is used to represent which AVPs defined in this document are
to be present in the Accounting messages, as defined in <xref target="RFC3588"/>.</t>
<t>
<figure>
<artwork><![CDATA[
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP6-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 0-1 | 0 |
-------------------------------------|------+------+
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This section contains the namespaces that have either been created in this specification or
had their values assigned to existing namespaces managed by IANA.</t>
<section title="Command Codes">
<t> IANA is requested to allocate a command code value for the MIP6-Request-Message (MRM)
and for the MIP6-Answer-Message (MAM) from the Command Code namespace defined in <xref
target="RFC3588"/>. See <xref target="Command-Code-Values"/> for the assignment of the
namespace in this specification. </t>
</section>
<section title="AVP Codes">
<t> This specification requires IANA to register the following new AVPs from the AVP Code
namespace defined in <xref target="RFC3588"/>. <list style="symbols">
<t>MIP-Careof-Address</t>
<t>MIP-Authenticator</t>
<t>MIP-MAC-Mobility-Data</t>
<t>MIP-Timestamp</t>
</list> The AVPs are defined in <xref target="avps"/>. </t>
</section>
<section title="Result-Code AVP Values">
<t> This specification requests IANA to allocate new values to the Result-Code AVP (AVP Code
268) namespace defined in <xref target="RFC3588"/>. See <xref target="result"/> for the
assignment of the namespace in this specification. </t>
</section>
<section title="Application Identifier">
<t> This specification requires IANA to allocate a new value for "Diameter Mobile IPv6" from
the Application Identifier namespace defined in <xref target="RFC3588"/>. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<t> The security considerations for the Diameter interaction required to accomplish the split
scenario are described in in <xref target="I-D.ietf-mip6-bootstrapping-split"/>.
Additionally, the security considerations of the Diameter Base protocol <xref
target="RFC3588"/>, Diameter EAP application <xref target="RFC4072"/> are applicable to
this document. This document does not introduce new security vulnerabilities. </t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<!-- t>The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi Eronen, Santiago Zapata
Hernandez, Anders Kristensen, Avi Lior, John Loughney, Ahmad Muhanna, Behcet Sarikaya,
Basavaraj Patil, Vijay Devarapalli, Lionel Morand and Yoshihiro Ohba for all the useful
discussions. Ahmad Muhanna and Jouni Korhonen provided a detailed review of the document in
July and August 2007.</t -->
<t>The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi Eronen, Santiago Zapata
Hernandez, Anders Kristensen, Avi Lior, John Loughney, Ahmad Muhanna, Behcet Sarikaya,
Basavaraj Patil, Vijay Devarapalli, Lionel Morand and Yoshihiro Ohba for all the useful
discussions. Ahmad Muhanna provided a detailed review of the
document in August 2007.</t>
<t>We would also like to thank our Area Director, Dan Romascanu, for his support.</t>
<t>Hannes Tschofenig would like to thank the European Commission support in the co-funding of
the ENABLE project, where this work is partly being developed.</t>
<t>Julien Bournelle would like to thank GEN/INT since he began this work while he was under
their employ.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References"> &RFC4640; &RFC4306; &RFC4004;
&RFC4072; &RFC3588; &RFC2119; &RFC4005; &RFC3775;
&I-D.ietf-mip6-rfc4285bis; &I-D.ietf-dime-qos-attributes;
&I-D.ietf-dime-mip6-integrated; &RFC4877; </references>
<references title="Informative References"> &I-D.ietf-mip6-aaa-ha-goals; &RFC4283;
&I-D.ietf-dime-app-design-guide; &I-D.ietf-mip6-bootstrapping-integrated-dhc;
&I-D.ietf-mip6-bootstrapping-split;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:15 |