Diameter MIPv6 [RFC5778] AVPs
Diameter Mobile IPv6 (MIPv6) (application id: 7 / 8)
(application id: 7 in IKEv2 scenarios, 8 in Mobile IPv6 Authentication Protocol scenarios)
The Diameter Mobile IPv6 (MIPv6) interface, as specified in [RFC5778], is a crucial component in supporting Mobile IPv6 operations within a Diameter-based Authentication, Authorization, and Accounting (AAA) infrastructure. The interface ensures that mobile nodes (MNs), which move across different networks while maintaining a consistent IP address, are properly authenticated, authorized, and accounted for.
The primary purpose of the Diameter MIPv6 interface is to facilitate the interaction between the Home Agent (HA) and the AAA server to support secure and efficient Mobile IPv6 operations. This interaction includes verifying the identity of the MN, authorizing its access to Mobile IPv6 services, and accounting for its usage of these services.
In Mobile IPv6, an MN must register with its HA to maintain its reachability as it moves across networks. The HA manages the association between the MN’s Home Address (a permanent IP address) and its Care-of Address (the IP address it acquires in the visited network). The Diameter MIPv6 interface ensures that the AAA infrastructure can verify the MN's identity and service entitlements throughout this process.
The architecture of the Diameter MIPv6 interface:
- Mobile Node (MN): The device that changes its point of attachment across different networks but retains a consistent Home Address.
- Home Agent (HA): The entity responsible for maintaining the binding between the MN’s Home Address and its current Care-of Address, facilitating the routing of packets to the MN’s current location.
- AAA Server: The server that provides the necessary authentication, authorization, and accounting services. It ensures that the MN is authorized to use Mobile IPv6 services and that its usage is properly accounted for.
Diameter Applications in MIPv6
RFC 5778 defines two specific Diameter applications for MIPv6:
- MIP6I (Application ID 7): Used when the MN is authenticated and authorized using IKEv2 (Internet Key Exchange version 2).
- MIP6A (Application ID 8): Used when the MN is authenticated and authorized using the Mobile IPv6 Authentication Protocol.
These applications handle the signaling between the HA and the AAA server to ensure secure and authorized Mobile IPv6 operations.
Diameter MIPv6 interface workflow:
Registration Request:
- The MN initiates a registration process with the HA. This process may involve exchanging security credentials and setting up IPsec security associations between the MN and the HA.
- The HA, acting as a Diameter client, sends a Diameter request to the AAA server to authenticate and authorize the MN. This request includes relevant information such as the MN’s identity and any necessary credentials.
Authentication and Authorization:
- The AAA server processes the request, validating the MN's credentials and verifying its authorization to use Mobile IPv6 services. The type of authentication (e.g., IKEv2 or Mobile IPv6 Authentication Protocol) dictates the specific Diameter application (MIP6I or MIP6A) used.
- If successful, the AAA server sends a response back to the HA, confirming the MN's authentication and authorization.
Session Management:
- The HA manages the session state for the MN, ensuring that the MN remains authenticated and authorized as it moves between networks. This involves maintaining the binding between the MN's Home Address and its current Care-of Address.
- If the MN's session state changes (e.g., due to movement across networks), the HA updates the session information with the AAA server.
Accounting:
- The HA reports the MN's usage of Mobile IPv6 services to the AAA server. This accounting information is critical for billing purposes and for ensuring that service providers can track and manage the MN’s resource usage.
Service Termination:
- When the MN no longer requires Mobile IPv6 services, the HA terminates the session. The final accounting information is sent to the AAA server to close the session and finalize the billing records.
For complete technical specification of Diameter MIPv6 interface in Diameter protocol please refer to: [RFC5778]
package com.mobius.software.telco.protocols.diameter.primitives.rfc5778
Name |
AVP Code |
Data Type |
Vendor |
Chargeable-User-Identity |
89 |
OctetString |
IETF |
Contains a unique, temporary identifier associated with the user. This AVP is defined to facilitate charging and accounting purposes without revealing the actual user identity, as specified in [RFC4372]. The Chargeable-User-Identity is designed to be a temporary handle, ensuring user privacy while allowing the system to identify users for billing and charging use cases. |
|||
MIP6-Auth-Mode |
494 |
Enumerated |
IETF |
Contains the Mobile IPv6 (MIPv6) Authentication Protocol mode used during interactions between the Mobile Node (MN) and the AAA infrastructure. This AVP defines the method for authenticating Binding Updates in the context of Mobile IPv6 networks, as described in [RFC4285]. Enumerated Values: 0: MIP6_AUTH_MN_AAA: Indicates that the MN-AAA security association is used for authenticating the Binding Update. When the MIP6-Auth-Mode AVP is set to the value MIP6_AUTH_MN_AAA, the Auth-Request-Type AVP must also be set to AUTHORIZE_AUTHENTICATE. |
|||
MIP-Authenticator |
488 |
OctetString |
IETF |
Contains the authenticator data extracted from the Binding Update (BU) message in Mobile IPv6 communication. This data originates from the MN-AAA Mobility Message Authentication Option included in the received BU message. When the MIP6-Auth-Mode AVP is set to MIP6_AUTH_MN_AAA, the MIP-Authenticator AVP must be included in the Mobile IPv6 Request (MIR) message. |
|||
MIP-Careof-Address |
487 |
Address |
IETF |
Provides the care-of address (CoA) of a mobile node in a Mobile IPv6 or IPv4 network. The care-of address represents the temporary IP address that the mobile node (MN) acquires when it connects to a foreign network. The Home Agent (HA) extracts this IP address from the received Binding Update (BU) message sent by the mobile node. |
|||
MIP-MAC-Mobility-Data |
489 |
OctetString |
IETF |
Contains the MAC Mobility Data computed by the Home Agent (HA) as defined in [RFC4285]. This data is used as part of the MN-AAA Mobility Message Authentication Option, which ensures the integrity and authenticity of Binding Update (BU) messages exchanged between the mobile node (MN) and the Home Agent (HA). When the MIP6-Auth-Mode AVP is set to MIP6_AUTH_MN_AAA, the MIP-MAC-Mobility-Data AVP must be included in the Mobile Initiated Request (MIR) message. |
|||
MIP-MN-HA-MSA |
492 |
Grouped |
IETF |
Contains session-related information required for the Mobile IPv6 Authentication Protocol, facilitating secure communication between the Mobile Node (MN) and the Home Agent (HA). This AVP ensures the proper handling of security associations and session keys critical for the MN-HA Authentication Option. The AVP structure is defined as follows: MIP-Session-Key (Mandatory): Contains the cryptographic session key shared between the MN and HA. MIP-MSA-Lifetime (Mandatory): Specifies the session's validity period in seconds. MIP-MN-HA-SPI (Optional): Identifies the SPI for the MN-HA security association. MIP-Algorithm-Type (Optional): Specifies the cryptographic algorithm used (e.g., HMAC-SHA-1). MIP-Replay-Mode (Optional): Defines the replay protection mode. Absence means no replay protection. 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. |
|||
MIP-MN-HA-SPI |
491 |
Unsigned32 |
IETF |
Contains the Security Parameter Index (SPI) value used to identify the security association required for the validation of the Mobile IPv6 MN-HA Authentication Option. This value works in conjunction with other parameters in establishing or validating secure communication between the Mobile Node (MN) and the Home Agent (HA). This AVP is mandatory when the following conditions are met: The MIP6-Auth-Mode AVP is set to MIP6_AUTH_MN_AAA. The Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA message. The MIP-MN-HA-SPI AVP must appear within the MIP-MN-HA-MSA grouped AVP. |
|||
MIP-Timestamp |
490 |
OctetString |
IETF |
Contains a 64-bit timestamp value (8 octets) used for replay protection in Mobile IPv6 signaling. This timestamp is extracted from the Mobility message replay protection option, as defined in [RFC4285]. It ensures that authentication messages between the Mobile Node (MN) and the Home Agent (HA) are not reused maliciously, thus maintaining the integrity and security of the communication. 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). |
|||
Service-Selection |
493 |
UTF8String |
IETF |
Contains the name of the service or the external network that the mobility service is associated with. Its purpose is to identify the specific service or network context for mobility interactions between the client and the server. If present in both request and reply messages, the AVP should contain the same service name. A mismatch in service names may be treated by the Home Agent (HA) as an authorization failure. Extracted from the IKEv2 IDr payload in the IKE_AUTH message, if present. Derived from the Service Selection Mobility Option as defined in [RFC5149], when available in the Binding Update (BU) message. If the request message does not include this AVP, the Diameter server may assign a default service and include the AVP in the reply message to inform the Home Agent (HA) of the assignment. |
Start innovating with Mobius
What's next? Let's talk!