One document matched: draft-ietf-dime-mip6-split-17.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="yes"?>
<?rfc compact="no" ?>
<?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 RFC4285 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4285.xml'>
<!ENTITY RFC4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY RFC4372 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4372.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 RFC5026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026.xml'>
<!ENTITY RFC5149 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5149.xml'>
<!ENTITY RFC5142 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5142.xml'>
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY RFC5419 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5419.xml'>
<!ENTITY RFC5447 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5447.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-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-mext-nemo-v4traversal PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-v4traversal.xml'>
<!ENTITY I-D.ietf-monami6-multiplecoa PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-monami6-multiplecoa.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-dime-mip6-split-17.txt">
<front>
<title abbrev="Diameter MIPv6: 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>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>FIN-02600</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.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>FIN-02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</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="G." surname="Giaretta" fullname="Gerardo Giaretta">
<organization abbrev="Qualcomm">Qualcomm</organization>
<address>
<postal>
<street>5775 MoreHouse Dr</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</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="2009"/>
<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.
This document specifies the interaction between a Mobile IP Home Agent and a
Diameter server.</t>
<t>This
document defines the Home Agent to the Diameter server communication when
the mobile node authenticates using the Internet Key Exchange v2 protocol with the
Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In
addition to authentication and 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 to have an assigned Home Agent
(HA) to the MN. The MN needs to register with the HA in order to enable
its reachability and mobility, when away from its home link. The registration
process itself may require an establishment of IPsec security associations
(SA) and cryptographic material between the MN and the HA. Alternatively, the
registration process may be secured using a mobility message authentication
option, which enables IPv6 mobility in a MN without having to establish an
IPsec SA with its 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
Authentication, Authorization, and Accounting (AAA) server. This specification
satisfies the requirements defined in <xref
target="I-D.ietf-mext-aaa-ha-goals"/> for the bootstrapping problem in
the split scenario <xref target="RFC5026"/> and also specifies Diameter support for the
Authentication Protocol for Mobile IPv6 <xref
target="RFC4285"/>. The Diameter support
defined in this specification also applies to Dual Stack
Mobile IPv6 <xref target="I-D.ietf-mext-nemo-v4traversal"/>.
</t>
<t>From a Mobility Service Provider (MSP) perspective, it is important to verify
that the MN is authenticated and authorized to utilize Mobile
IPv6 service, and is accounted for those. Only when the MN is authenticated and authorized, the MSP allows
the bootstrapping of Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6
registrations, 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 infrastructure. The HA, due to its role in traffic forwarding, 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:">Verifying the MN's 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 the
Mobile IPv6 service using the assistance of the MSP Diameter servers. This is
accomplished through the use of new Diameter applications specifically designed for
performing Mobile IPv6 authorization decisions. This
document defines required AAA procedures 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
that the HA provides accounting reports to the Diameter infrastructure and thus to
support the related Diameter accounting procedures.<vspace blankLines="1"/>
</t>
<t hangText="Session Management:">The management of the
mobility services may require the Diameter server or the HA to
terminate the Mobile IPv6 service before the binding
expires. This document defines procedures for the AAA based session
management.<vspace blankLines="1"/>
</t>
</list>
</t>
<t>
<xref target="arch-mip6"/> depicts the reference architecture
for this document.</t>
<figure anchor="arch-mip6" title="Architecture Overview">
<artwork><![CDATA[
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | Diameter Mobile IPv6
Protocol | HA<->AAA Server
Support | Interaction
| (this document)
v
+---------+ +---------------+
| Mobile | Front-End Protocol |Home Agent / |
| Node |<-------------------->|Diameter Client|
+---------+ IKEv2 or RFC 4285 +---------------+
]]></artwork>
</figure>
<t>Mobile IPv6 signaling between the MN and the HA can be protected using two different
mechanisms, namely using IPsec or the Authentication Protocol for Mobile IPv6
<xref target="RFC4285"/>.
For these two approaches several different
authentication and key exchange solutions are available. When
IPsec is used to protect Mobile IPv6 signaling messages, Internet Key Exchange
v2 (IKEv2) is
used <xref target="RFC4877"/> for the setup of the IPsec SAs. IKEv2 supports
Extensible Authentication Protocol (EAP) based initiator authentication,
certificates and pre-shared
secrets. Alternatively, the Authentication Protocol for Mobile IPv6 uses a
mechanism that is very similar to the one used for protecting
Mobile IPv4 signaling messages.
</t>
<t>The ability to use different credentials and methods to
authenticate the MN has an impact on the AAA interactions
between the HA (acting as a Diameter client) and the Diameter
Server. This specification is only limited to the following
MN authentication methods:
</t>
<t>
<list style="symbols">
<t>IKEv2 usage with EAP</t>
<t>Mobile IPv6 Authentication Protocol</t>
</list>
</t>
<t>New authentication mechanisms may be added later by separate specifications.
</t>
<t>For accounting of Mobile IPv6 services provided to the MN, this specification uses the
Diameter Base Protocol accounting 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 <xref target="RFC2119"/>.
</t>
<t>The Mobile IPv6 bootstrapping terminology is taken from <xref
target="RFC4640"/>. Additional terminology is defined below:
</t>
<t>
<list style="hanging">
<t hangText="Authentication, Authorization, and Accounting (AAA):">
<vspace blankLines="1"/>
AAA protocol based on Diameter <xref
target="RFC3588"/> with required EAP support <xref
target="RFC4072"/>.
<vspace blankLines="1"/>
</t>
<t hangText="Home AAA (AAAH):">
<vspace blankLines="1"/> An authentication,
authorization and accounting server
located in user's home network i.e., in the home
realm.
</t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="Application Identifiers">
<t>This specification defines two new Diameter applications and
their respective Application Identifiers:
</t>
<figure><artwork><![CDATA[
Diameter Mobile IPv6 IKE (MIP6I) TBD by IANA
Diameter Mobile IPv6 Auth (MIP6A) TBD by IANA
]]>
</artwork></figure>
<t>The MIP6I Application Identifier is used when the MN is authenticated
and authorized using IKEv2. The MIP6A Application Identifier is used
when the MN is authenticated and authorized using the Mobile IPv6
Authentication Protocol.
</t>
<t>Mobile IPv6 related accounting information generated by the HA uses
either the MIP6I or the MIP6A Application Identifier in the case of coupled
accounting model. The Diameter Base Accounting Application Identifier
(value of 3) is used in case of the split accounting
model. Refer to <xref target="accounting_models"/> for more information
regarding the accounting models.
</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 logic and procedures, as defined in <xref
target="RFC4072"/>, are 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 <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. The
communication between the mobile node and the home agent use the
conventions defined in <xref target="RFC4306"/>. Similarly,
the communication between the home agent and the Diameter server use
the conventions defined in <xref target="RFC4072"/>.
</t>
<figure anchor="fig-ikev2-diameter-msg" title="Mobile IPv6 bootstrapping using IKEv2 and EAP">
<artwork><| |
|<--------------------------------| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | DER (EAP-Response) (4) + |
|-------------------------------->| MIP6 Bootstrapping AVPs |
| |------------------------->|
| | |
| | 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) + |
| | MIP6 Bootstrapping AVPs |
| 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 MN's Diameter server/EAP server. The Diameter server selects
the EAP method and replies with the Diameter-EAP-Answer (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 signaling.
</t>
<t>In some deployment scenarios, the HA may also act as an IKEv2
Responder for a conventional IPsec VPN access. The challenge in this case is that the
IKEv2 responder may not know if IKEv2 is used for Mobile IPv6
service or for IPsec VPN access service. A network operator needs to
be aware of this limitation. One solution already supported by IKEv2
is to use different responder identities when operating as a
conventional IPsec VPN gateway or as a HA. The MN can then indicate
the preferred responder type using the appropriate IDr payload in
the IKE_AUTH message.
</t>
<t>Eventually, when the HA receives a Binding Update (BU), the HA
authenticates and authorizes the
MN. It is RECOMMENDED that the HA sends an accounting request message
every time it receives a BU.
</t>
</section>
<section title="Support for the Mobile IPv6 Authentication Protocol">
<t>
<xref target="rfc4285-flow"/> shows the message sequence
between the MN, the HA and the Diameter server during the
registration when Mobile IPv6 Authentication Protocol is
used. A BU and a Binding Acknowledgement (BA) messages are used
in the binding registration process.
</t>
<t>Receiving a BU at the HA initiates a MIP6-Request
to be sent to the Diameter server. The Diameter server in
turn responds with a MIP6-Answer. The HA
may assign a Home Address to the MN and provide it to the
Diameter server in the MIP-Mobile-Node-Address AVP.
</t>
<t>According to <xref target="RFC4285"/> the
MN uses the Mobile Node Identifier Option, specifically the
MN-NAI mobility option (as defined in <xref
target="RFC4283"/>) to identify itself. The HA MUST copy the
MN-NAI mobility option value to the User-Name AVP in the
subsequent request messages.
</t>
<t>The procedure described in this specification for the
Mobile IPv6 Authentication Protocol is only needed for the
initially received BU for which the HA does not have an
existing security association. When the HA receives
subsequent BUs, they are processed locally in the HA. It is
RECOMMENDED that the HA sends an accounting request message
every time it receives a Binding Update. However, the HA
MAY re-authorize the MN with the Diameter server at any
time depending on the deployment and the local policy.
</t>
<t>This specification assumes that in the case Mobile IPv6
Authentication Protocol is used, the MN-AAA option is included in the
BU as defined in <xref target="RFC4285"/> and the Diameter
server computes required session keys after having successfully
authenticated the MN. The computation of the session keys is out of
scope of this specification. Other possible ways of using Mobile
IPv6 Authentication Protocol are also out of scope of this
specification and would require a new specification to describe the
detailed behavior of the HA-AAAH interface and corresponding session
key derivation.
</t>
<!--t> The HA-AAAH interface
has been designed in a way that the Mobile IPv6 Authentication Protocol
may also be used in different modes, for example, with or without the MN-AAA
option. There can be networking architectures and deployments where the MN-HA
security associations is established as a result of a successful network access
authentication. In such deployments, both the MN and the Diameter server
share the keying material required for computation and validation of the
MN-HA Authentication Option, and a Security Parameter Index (SPI) for
indexing an appropriate security association. The Diameter request message
sent by the HA must contain enough information (such as SPI, MN-NAI, etc)
so that the Diameter server is able to locate the matching MN-HA security
association and return correct keying material back to the HA.
</t-->
<!--t>In some architectures and network deployments the MN-HA
security associations may be established as a result of a
successful network access authentication. In such
deployments, both the MN and the Diameter server share the keying
material required for computation and validation of the MN-HA
Authentication Option, and a Security Parameter Index (SPI)
for indexing an appropriate security association. Upon
receiving a BU with a MN-HA Authentication Option, the HA
retrieves the keying material required for the computation
and validation of the MN-HA
Authentication Option from the Diameter server. The
Diameter request message sent by the HA must contain enough
information (such as SPI, MN-NAI, etc) so that the Diameter
server is able to locate the matching MN-HA security
association and return correct keying material back to the
HA.
</t-->
<t>
<figure anchor="rfc4285-flow" title="Mobile IPv6
Bootstrapping using the Mobile IPv6 Authentication
Protocol">
<artwork><![CDATA[
Mobile Home Diameter
Node Agent Server
| | |
| | MIP6-Request + MIP6 |
| Binding Update | Bootstrapping AVPs |
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | MIP6-Answer + MIP6 |
| Binding Acknowledgement | Bootstrapping AVPs |
|<------------------------------------|<--------------------|
| (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"/>.
</t>
<t>This specification makes an assumption that each SA created
between the MN and the HA as a result of a successful IKEv2
negotiation or a Mobile IPv6 Authentication
Protocol exchange correspond to one Diameter session. In IKEv2
case we specifically mean the created IKE SA.
</t>
<section title="Session-Termination-Request">
<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. This means that the HA MUST terminate the
corresponding Mobile IPv6 binding and also
terminate the corresponding SA.
</t>
</section>
<section title="Session-Termination-Answer">
<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">
<t>The Abort-Session-Request (ASR) message <xref target="RFC3588"/> is sent by the
Diameter server to the HA to terminate the authorized session. This fulfills one
of the requirement
described in <xref target="I-D.ietf-mext-aaa-ha-goals"/>. When the HA receives
the ASR message, it MUST terminate the corresponding SA. Subsequently,
the HA MUST take further actions to terminate the corresponding Mobile IPv6
binding.
</t>
</section>
<section title="Abort-Session-Answer">
<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" anchor="accounting_models">
<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 Identifier (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 preferred
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 either the MIP6I
or the MIP6A Application Identifiers. 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 preferred choice is to use the split accounting model and thus to
choose Diameter Base Accounting Application Identifier (value of 3) for accounting messages.</t>
<section title="Accounting-Request">
<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">
<t>The Accounting-Answer command <xref target="RFC3588"/> is sent by the Diameter server
to the HA to acknowledge 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 the use of Mobile IPv6 with IKEv2 and EAP this document
reuses the Diameter EAP application <xref target="RFC4072"/>
commands: Diameter-EAP-Request (DER) and Diameter-EAP-Answer
(DEA).
This specification extends the existing DER and DEA command ABNFs
with a number of AVPs to support Mobile IPv6
split scenario bootstrapping. Other than new additional AVPs
and the corresponding additions to the command ABNFs, the
Diameter EAP application command ABNFs remain unchanged. The
ABNF language is defined in <xref target="RFC3588"/>.
</t>
<t>
<figure anchor="cmd-eap" title="Command Codes">
<artwork><![CDATA[
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE
Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE
]]></artwork>
</figure>
</t>
<section title="Diameter-EAP-Request">
<t>The Diameter-EAP-Request (DER) message, 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 Application-ID field of the Diameter Header MUST be set to the
Diameter Mobile IPv6 IKE Application ID (value of TDB).</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 ]
[ MIP6-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ QoS-Capability ]
* [ QoS-Resources ]
...
* [ AVP ]
]]></artwork>
</figure>
</t>
<t>Mobile IPv6 bootstrapping AVPs are only included in the
first DER message send by the HA. The subsequent DER
messages required
by the EAP-method do not need to include any Mobile
IPv6 bootstrapping AVPs. The MN is both authenticated and
authorized for the mobility service during the EAP
authentication. Thus, the Auth-Request-Type AVP MUST be set to
the value AUTHORIZE_AUTHENTICATE.
</t>
</section>
<section title="Diameter-EAP-Answer">
<t>The Diameter-EAP-Answer (DEA) message, 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). The
Application-Id field in the Diameter message header MUST be set to the Diameter Mobile IPv6
IKE Application-Id (value of TBD). If the Mobile IPv6
authentication procedure was successful then the response MAY include any set of
bootstrapping AVPs.
</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 ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time ]
...
*2[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
[ Service-Selection ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
...
* [ AVP ]
]]></artwork>
</figure>
</t>
<t>If the EAP-based authentication and the authorization for the
mobility service succeeds, then the Mobile IPv6
bootstrapping AVPs are included in the last DEA message
that also carries the EAP-Success EAP payload. The other
DEA messages required by the used EAP-method do not
include any Mobile IPv6 bootstrapping AVPs.
</t>
<!--t>It should be noted that the IPSec SA created between the MN and
the HA is mapped to the created Diameter session identifier.
The lifetime of the IPsec SA might be longer than the Mobile
IPv6 binding lifetime.
</t-->
</section>
</section>
<section title="Command Codes for Mobile IPv6 Authentication Protocol Support">
<t>This section defines the commands that are used for
support with the Mobile IPv6 Authentication
Protocol.
</t>
<t>There are multiple ways of deploying and utilizing Mobile
IPv6 Authentication Protocol, especially regarding the
associated AAA interactions. In order to support multiple
deployment models this specification defines the
MIP6-Auth-Mode AVP that in the request message tells the
mode that the HA supports. This specification defines a
method that requires the use of the MN-AAA option with the
Mobile IPv6 Authentication Protocol.
</t>
<t>
<figure title="Command Codes">
<artwork><![CDATA[
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
MIP6-Request MIR TBD 5.3.1 Diameter Mobile IPv6 Auth
MIP6-Answer MIA TBD 5.3.2 Diameter Mobile IPv6 Auth
]]></artwork>
</figure>
</t>
<section title="MIP6-Request">
<t>The MIP6-Request (MIR), 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.</t>
<t>Although the HA provides the Diameter server with replay protection related
information, the HA is responsible for the replay protection.
</t>
<t>The message format is shown below.</t>
<t>
<figure>
<artwork><![CDATA[
<MIP6-Request> ::= < Diameter Header: TBD, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ MIP6-Feature-Vector ]
{ MIP6-Auth-Mode }
[ MIP-MN-AAA-SPI ]
[ MIP-MN-HA-SPI ]
1*2{ MIP-Mobile-Node-Address }
{ MIP6-Agent-Info }
{ MIP-Careof-Address }
[ MIP-Authenticator ]
[ MIP-MAC-Mobility-Data ]
[ MIP-Timestamp ]
[ QoS-Capability ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
]]></artwork>
</figure>
</t>
<t>If the MN is both authenticated and authorized for the
mobility service, then the Auth-Request-Type AVP is set to
the value AUTHORIZE_AUTHENTICATE. This is the case when
the MIP6-Auth-Mode is set to the value MIP6_AUTH_MN_AAA.
</t>
</section>
<section title="MIP6-Answer">
<t> The MIP6-Answer (MIA) 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. The User-Name AVP MAY be included in the MIA
if it is present in the MIR. The Result-Code AVP MAY contain one of the values defined
in <xref target="result"/>, in addition to the values defined in <xref
target="RFC3588"/>.</t>
<t>An MIA 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> ::= < Diameter Header: TBD, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP6-Feature-Vector ]
[ MIP-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ MIP-MN-HA-MSA ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Failed-AVP ]
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="avps" title="AVPs">
<t>To provide support for <xref target="RFC4285"/> and for
<xref target="RFC4877"/> the AVPs in the following subsections are
needed. <xref target="RFC3588"/>, <xref target="RFC4004"/> and
<xref target="RFC4005"/> defined AVPs are
reused whenever possible without changing the existing
semantics of those AVPs.
</t>
<t>
<figure title="AVPs for Mobile IPv6 IKE Application">
<artwork><![CDATA[
+--------------------+
| AVP Flag rules |
+----+---+------+----+----+
AVP Defined | | |SHOULD|MUST|MAY |
Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr|
+-----------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-Mobile- | M | P | | V | Y |
| Node-Address 334 RFC4004 Address | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC5447 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|User-Name 1 RFC3588 UTF8String | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|Service- TBD 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+-----------------------------------------+----+---+------+----+----+
|QoS-Capability TBD Note 1 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|QoS-Resources TBD Note 1 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA TBD 6.12 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+-----------------------------------------+----+---+------+----+----+
]]></artwork>
</figure>
</t>
<!--t>Note 1: The MIP6-Feature-Vector AVP is defined in Section 4.2.5 of <xref
target="RFC5447"/>.
</t-->
<t>Note 1: The QoS-Capability and the QoS-Resource AVPs are defined
in Sections 4.1 and 4.3 of <xref
target="I-D.ietf-dime-qos-attributes"/>.
</t>
<!--t>Note 3: The MIP6-Agent-Info AVP is defined in Section 4.2.1 of <xref
target="RFC5447"/>.
</t-->
<t>
<figure title="AVPs for the Mobile IPv6 Auth Application">
<artwork><![CDATA[
+--------------------+
| AVP Flag rules |
+----+---+------+----+----+
AVP Section | | |SHOULD|MUST|MAY |
Attribute Name Code Defined Value Type |MUST|MAY| NOT | NOT|Encr|
+-----------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+-----------------------------------------+----+---+------+----+----+
|User-Name 1 RFC3588 UTF8String | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|Service- TBD 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-MN-HA-SPI TBD 6.4 Unsigned32 | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-Mobile- 333 RFC4004 Address | M | P | | V | Y |
| Node-Address | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC5447 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-Careof- TBD 6.7 Address | M | P | | V | Y |
| Address | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP- TBD 6.8 OctetString| M | P | | V | Y |
| Authenticator | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-MAC- TBD 6.9 OctetString| M | P | | V | Y |
| Mobility-Data | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y |
| Lifetime | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA TBD 6.12 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y |
| Type | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|MIP-Timestamp TBD 6.16 OctetString| M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|QoS-Capability TBD Note 1 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|QoS-Resources TBD Note 1 Grouped | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+-----------------------------------------+----+---+------+----+----+
|MIP6-Auth-Mode TBD 6.20 Enumerated | M | P | | V | Y |
+-----------------------------------------+----+---+------+----+----+
|Rest of the AVPs RFC3588 | M | P | | V | Y |
|in the MIR & MIA RFC4005 | | | | | |
|excluding *[AVP] | | | | | |
+-----------------------------------------+----+---+------+----+----+
]]></artwork>
</figure>
</t>
<!--t>Note 1: The MIP6-Feature-Vector AVP is defined in Section 4.2.5 of <xref
target="RFC5447"/>.
</t-->
<t>Note 1: The QoS-Capability and the QoS-Resource AVPs are defined
in Sections 4.1 and 4.3 of <xref
target="I-D.ietf-dime-qos-attributes"/>.
</t>
<!--t>Note 3: The MIP6-Agent-Info AVP is defined in Section 4.2.1 of <xref
target="RFC5447"/>.
</t-->
<section title="User-Name AVP">
<t>The User-Name AVP (AVP Code 1) 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_AUTH message sent by the
IKE initiator. </t>
</section>
<section title="Service-Selection AVP">
<t>The Service-Selection AVP (AVP Code TBD) is of type
UTF8String and contains the name of the service or the
external network that the mobility service should be
associated with. In the scope of this specification the value
can extracted from the IKEv2 IDr payload, if available in
the IKE_AUTH message sent by the IKE
initiator. Alternatively, if the Mobile IPv6
Authentication Protocol is used, then the Service-Selection AVP contains the string
extracted from the Service Selection Mobility Option <xref
target="RFC5149"/>, if available in the received
BU. Future specification may define additional ways to
populate the Service-Selection AVP with the required
information.
</t>
<t>The AVP is also available to be used in messages sent from
the Diameter server to the Diameter client. For example, if the
request message did not contain the Service-Selection AVP but
the MN was assigned with a default service, the Diameter server MAY
return the name of the assigned default service to the HA.
</t>
<t>If the Service-Selection AVP is present in both the request and
the reply messages, it SHOULD contain the same service name. If
the services differ, the HA MAY treat that as authorization
failure.
</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. This AVP is re-used from <xref target="RFC4004"/>.
</t>
<t>When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this
AVP MUST be present in the MIR message.
</t>
</section>
<section title="MIP-MN-HA-SPI AVP">
<t>The MIP-MN-HA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains
an SPI value that can be used with other parameters for identifying the
security association required for the validation of the Mobile IPv6
MN-HA Authentication Option.
</t>
<t>When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and
the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA
message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
</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 HA
assigned IPv6 or IPv4 Home Address of the Mobile Node. </t>
<t> If the MIP-Mobile-Node-Address AVP contains the unspecified
IPv6 address (0::0) or the all zeroes IPv4 address (0.0.0.0) in a request
message, then the HA expects the Diameter server to assign the Home Address in a
subsequent answer message. If the Diameter server
assigns only an IPv6 Home Network
Prefix to the Mobile
Node the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address MUST be set to
zero.</t>
<t> This AVP is re-used from <xref target="RFC4004"/>.</t>
</section>
<section title="MIP6-Agent-Info AVP">
<t>The MIP6-Agent-Info AVP (AVP Code 486) is defined in Section 4.2.1 of <xref
target="RFC5447"/> and contains the IPv6
or the IPv4 address information of the HA. The HA address in a
request message is the same as in the received BU
message that triggered the authentication and authorization
procedure towards the Diameter server. One use case is e.g., to inform the
Diameter server of the dynamically assigned HA.
</t>
<t>If the MIP6-Agent-Info AVP is present in an answer
message and the Result-Code AVP is set to DIAMETER_SUCCESS_RELOCATE_HA, then the
Diameter server is indicating to the HA that it MUST
initiate a HA switch procedure towards the MN
(e.g., using the procedure defined in <xref
target="RFC5142"/>). If the Result-Code AVP is set to any
other value, then the HA SHOULD initiate the HA
switch procedure towards the MN. The address information of the assigned HA
is defined in the MIP6-Agent-Info AVP.
</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
or the IPv4
Care-of Address of the Mobile Node. The HA 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 HA extracts this data from the MN-AAA Mobility Message
Authentication Option included in the received BU message.
</t>
<t>When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA,
this AVP MUST be present in the MIR 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 MAC_Mobility_Data calculated by the HA as defined
in <xref target="RFC4285"/> for the MN-AAA Mobility Message
Authentication Option.
</t>
<t>When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA,
this AVP MUST be present in the MIR message.
</t>
</section>
<section title="MIP-Session-Key AVP" anchor="mip-session-key">
<t>The MIP-Session-Key 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.
How the Diameter server computes the session key is not defined in
this specification. The Session key derivation is deployment
specific and needs to be defines in a respective deployment specific
system specification.
</t>
<t>This AVP is re-used from <xref target="RFC4004"/>.
</t>
<!-- The
AVP MUST be encrypted using the method defined in <xref
target="RFC2868"/> Section 3.5
</t-->
</section>
<section title="MIP-MSA-Lifetime AVP">
<t>The MIP-MSA-Lifetime 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"/>)
is valid. The associated session key 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-MN-HA-MSA AVP">
<t>The MIP-MN-HA-MSA AVP (AVP Code TBD) is of type Grouped and contains the session related information
for use with the Mobile IPv6 Authentication Protocol.</t>
<t>
<figure>
<artwork><![CDATA[
MIP-MN-HA-MSA ::= < AVP Header: TBD >
{ MIP-Session-Key }
{ MIP-MSA-Lifetime }
[ MIP-MN-HA-SPI ]
[ MIP-Algorithm-Type ]
[ MIP-Replay-Mode ]
* [ AVP ]
]]></artwork>
</figure>
</t>
<t>The MIP-MN-HA-SPI sub-AVP within the MIP-MN-HA-MSA grouped AVP
identifies the security association required for the validation
of the Mobile IPv6 MN-HA Authentication Option. The absence of the
MIP-Replay-Mode AVP MUST be treated as no replay protection
was selected.
</t>
</section>
<section title="MIP-Algorithm-Type AVP">
<t>The MIP-Algorithm-Type 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
<xref target="RFC4004"/> that also fulfill current
RFC 4285 requirements. This AVP is re-used from
<xref target="RFC4004"/>.
</t>
<t>When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and
the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA
message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
</t>
</section>
<section title="MIP-Replay-Mode AVP">
<t>The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the HA
for authenticating the mobile node. Out of all possible replay modes
defined in <xref target="RFC4004"/>, the following
are supported by this specification:
</t>
<figure><artwork><![CDATA[
1 None
2 Timestamp
]]>
</artwork></figure>
<t>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"/>.
</t>
</section-->
<section title="MIP6-Feature-Vector AVP">
<t>The MIP6-Feature-Vector AVP (AVP Code 124) is defined in
<xref target="RFC5447"/>. However, this specification does not define
any Mobile IPv6 split scenario bootstrapping
specific capability flag.
</t>
<!--t><list style="hanging">
<t hangText="MIP6_SPLIT (0x0000000100000000)">
<vspace blankLines="1"/>
When this flag is set by the NAS then it means that the Mobile
IPv6 split scenario bootstrapping functionality is supported
by the NAS. When this flag is set by the Diameter server then the
Mobile IPv6 split scenario bootstrapping is supported by the
Diameter server.
<vspace blankLines="1"/>
</t>
</list>
</t-->
</section>
<section title="MIP-Timestamp AVP">
<t>The MIP-Timestamp AVP (AVP Code TBD) is of type OctetString and
contains eight octets timestamp value (i.e. 64 bits timestamp)
from the Mobility message replay protection option, defined in
<xref target="RFC4285"/>. The HA extracts this
value from the received BU message, if available.
The HA includes this AVP in the MIR message when
the MN-AAA Mobility Message Authentication Option is available in
the received BU and the Diameter server is expected to
return the key material required for the calculation
and validation of the Mobile IPv6 MN-HA Authentication
Option (and the MIP6-Auth-Mode AVP is set to value
MIP6_AUTH_MN_AAA).
</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="Chargeable-User-Identity AVP">
<t>The Chargeable-User-Identity AVP (AVP code 89) is of type
OctetString and contains an unique temporary handle of the
user. The Chargeable-User-Identity is defined in
<xref target="RFC4372"/>.
</t>
</section>
<section title="MIP6-Auth-Mode AVP">
<t>The MIP6-Auth-Mode (AVP Code TBD) is of type Enumerated and
contains information of the used Mobile IPv6 Authentication
Protocol mode. This specification defines only one value
MIP6_AUTH_MN_AAA and the corresponding AAA interactions when
MN-AAA security association is used to authenticate the
Binding Update as described in <xref target="RFC4285"/>.
When the MIP6-Auth_Mode AVP is set to the
value of MIP6_AUTH_MN_AAA, the Auth-Request-Type AVP MUST
be set to the value of AUTHORIZE_AUTHENTICATE.
</t>
<t>If the Diameter server does not support the Mobile IPv6
Authentication Protocol usage mode proposed by the HA, then
the Diameter server MUST fail the
authentication/authorization and MUST set the Result-Code AVP to
the value of DIAMETER_ERROR_AUTH_MODE.
</t>
</section>
<section anchor="accounting" title="Accounting AVPs">
<t>Diameter Mobile IPv6 applications, either MIP6I or MIP6A, are used
in the case of the coupled account model.
Diameter Mobile IPv4 application <xref target="RFC4004"/> accounting
AVPs are reused in this document. The following AVPs SHOULD be included in the
accounting request message:</t>
<t>
<list style="hanging">
<t hangText="o">Accounting-Input-Octets: Number of octets in IP
packets received from the mobile node.
</t>
<t hangText="o">Accounting-Output-Octets: Number of octets in IP
packets sent by the mobile node
</t>
<t hangText="o">Accounting-Input-Packets: Number of IP packets
received from the mobile node.
</t>
<t hangText="o">Accounting-Output-Packets: Number of IP packets
sent by the mobile node.
</t>
<t hangText="o">Acct-Multi-Session-Id: Used to link together
multiple related accounting sessions, where each session would have a unique
Session-Id, but the same Acct-Multi-Session-Id AVP.</t>
<t hangText="o">Acct-Session-Time: Indicates the length
of the current session in seconds.</t>
<t hangText="o">MIP6-Feature-Vector: The supported features for this mobility
service session.
</t>
<t hangText="o">MIP-Mobile-Node-Address: The Home Address of the mobile node.
</t>
<t hangText="o">MIP-Agent-Info: The current home agent of the mobile node.
</t>
<t hangText="o">Chargeable-User-Identity: The unique
temporary identity of the user. This AVP MUST be included
if it is available in the home agent.
</t>
<!-- was optional earlier -->
<t hangText="o">Service-Selection: Currently selected
mobility service.
</t>
<t hangText="o">QoS-Resources: Assigned QoS resources for the mobile node.
</t>
<t hangText="o">QoS-Capability: The
QoS capability related to the assigned QoS-Resources.
</t>
<t hangText="o">MIP-Careof-Address: The current Care-of Address of the
mobile node.
</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="Success">
<t>Errors that fall within the Success category are used to inform a
peer that a request has been successfully completed.
</t>
<t>
<list style="hanging">
<t hangText="DIAMETER_SUCCESS_RELOCATE_HA (Status Code TBD)"><vspace
blankLines="1"/> This result code is used by the Diameter
server to inform the HA that the MN MUST be
switched to another HA.
</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 (Status Code TBD)"><vspace
blankLines="1"/> This error code 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.
<vspace blankLines="1"/>
</t-->
<t hangText="DIAMETER_ERROR_MIP6_AUTH_MODE (Status Code
TBD)"><vspace blankLines="1"/> This error code is used
by the Diameter server to inform the peer that the
requested Mobile IPv6 Authentication Protocol usage
mode is not supported.
</t>
</list>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="AVP Occurrence 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="DER, DEA, MIR and MIA AVP/Command-Code Table">
<t>
<figure>
<artwork><![CDATA[
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | DER | DEA | MIR | MIA |
-------------------------------|-----+-----+-----+-----+
MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 |
MIP-MN-AAA-SPI | 0 | 0 | 0-1 | 0 |
MIP-MN-HA-SPI | 0 | 0 | 0-1 | 0 |
MIP6-Agent-Info | 1 | 0-1 | 1 | 0-1 |
MIP-Careof-Address | 0 | 0 | 0-1 | 0 |
MIP-Authenticator | 0 | 0 | 0-1 | 0 |
MIP-MAC-Mobility-Data | 0 | 0 | 0-1 | 0 |
MIP-MSA-Lifetime | 0 | 0 | 0 | 1 |
MIP-MN-HA-MSA | 0 | 0 | 0 | 0-1 |
MIP-Timestamp | 0 | 0 | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 | 1 | 0-1 |
Service-Selection | 0-1 | 0-1 | 0-1 | 0-1 |
QoS-Resources | 0+ | 0+ | 0+ | 0+ |
QoS-Capability | 0-1 | 0 | 0-1 | 0 |
Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 |
MIP6-Auth-Mode | 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="Coupled Accounting Model 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 | 0-1 | 0-1 |
Accounting-Input-Packets | 0-1 | 0-1 |
Accounting-Output-Octets | 0-1 | 0-1 |
Accounting-Output-Packets | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Acct-Session-Time | 0-1 | 0-1 |
MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Agent-Info | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 0-2 | 0-2 |
Event-Timestamp | 0-1 | 0 |
MIP-Careof-Address | 0-1 | 0 |
Service-Selection | 0-1 | 0 |
QoS-Capability | 0+ | 0+ |
QoS-Resources | 0+ | 0+ |
Chargeable-User-Identity | 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 following new commands
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>
<figure><artwork><![CDATA[
Command Code | Value
-----------------------------------+------
MIP6-Request (MIR) | TBD
MIP6-Answer (MIA) | TBD
]]>
</artwork></figure>
</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"/>.<vspace blankLines="1"/>
<list style="symbols">
<t>MIP-Careof-Address</t>
<t>MIP-Authenticator</t>
<t>MIP-MAC-Mobility-Data</t>
<t>MIP-Timestamp</t>
<t>MIP-MN-HA-SPI</t>
<t>MIP-MN-HA-MSA</t>
<t>Service-Selection</t>
<t>MIP6-Auth-Mode</t>
</list><vspace blankLines="1"/>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>
<figure><artwork><![CDATA[
Result-Code | Value
----------------------------------------------+------
DIAMETER_SUCCESS_RELOCATE_HA | TBD
DIAMETER_ERROR_MIP6_AUTH_MODE | TBD
]]>
</artwork></figure>
</section>
<section title="Application Identifier">
<t> This specification requires IANA to allocate two new
values "Diameter Mobile IPv6 IKE" and "Diameter Mobile
IPv6 Auth" from the Application Identifier namespace defined
in <xref target="RFC3588"/>.
</t>
<figure><artwork><![CDATA[
Application Identifier | Value
-----------------------------------+------
Diameter Mobile IPv6 IKE (MIP6I) | TBD
Diameter Mobile IPv6 Auth (MIP6A) | TBD
]]>
</artwork></figure>
</section>
<section title="Namespaces">
<!--t>This specification defines new values to the "Mobility
Capability" registry (see <xref
target="I-D.ietf-dime-mip6-integrated"/>)
for use with the MIP6-Feature-Vector
AVP:
<figure><artwork><![CDATA[
Token | Value | Description
---------------------------------+----------------------+------------
MIP6_SPLIT | 0x0000000100000000 | RFC TBD
]]></artwork></figure>
</t-->
<t>IANA is requested to create a new registry "MIP6
Authentication Mode" registry for use with the
enumerated MIP6-Auth-Mode AVP. The registry will initially
contain the following value:
<figure><artwork><![CDATA[
Token | Value | Description
---------------------------------------------+----------+------------
MIP6_AUTH_MN_AAA | 1 | RFC TBD
]]></artwork></figure>
</t>
<t>Allocation of new values follow the example policies
described in <xref target="RFC5226"/> new values for the
MIP6-Auth-Mode AVP will be assigned based on the "Specification
Required" policy. The value 0 (zero) is reserved and the
maximum value is 4294967295 (i.e. 2^32-1).
</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 <xref target="RFC5026"/>.
Additionally, the security considerations of the Diameter Base protocol <xref
target="RFC3588"/>, Diameter EAP application <xref target="RFC4072"/> are applicable to
this document.
</t>
<t>The Diameter messages may be transported between the HA and
the Diameter server via one or more AAA brokers or Diameter
agents. In this case the HA to the Diameter server AAA
communication rely on the security properties of the
intermediating AAA inter-connection networks, AAA brokers and Diameter
agents (such as proxies).
</t>
<t>In case of the Authentication Protocol for Mobile IPv6 <xref target="RFC4285"/>,
this specification expects that the Diameter server derives the
MN-HA Security Association and returns the associated session key (i.e.
the MN-HA shared session key) to the HA. However, this specification
does not define nor other IETF specification
defines how the Diameter server actually derives
required keys. The details of the key derivation depends on the
deployment where this specification is used and therefore the
security properties of the system depend on how this is done.
</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>The authors would like to thank 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, Domagoj
Premec, Semyon Mizikovsky and Yoshihiro Ohba for all the useful
discussions. Ahmad Muhanna provided a detailed review of the
document in August 2007. Pasi Eronen provided detailed comments and
text proposals during the IESG review that helped to improved this
document greatly.
</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 GET/INT since he began this work while he was under
their employ.</t>
<t>Madjid Nakhjiri would like to thank Huawei USA as most of his
contributions to this draft were possible while he was under
their employ.
</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&RFC4306;
&RFC4004;
&RFC4072;
&RFC3588;
&RFC2119;
&RFC4005;
&RFC3775;
&I-D.ietf-dime-qos-attributes;
&RFC5447;
&RFC4877;
&RFC5026;
&RFC5142;
&RFC4372;
&RFC4283;
&RFC4285;
&RFC5149;
</references>
<references title="Informative References">
&I-D.ietf-mext-aaa-ha-goals;
&I-D.ietf-dime-app-design-guide;
&RFC4640;
&RFC5226;
&I-D.ietf-mext-nemo-v4traversal;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:42 |