RFC 5779
Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server
RFC 5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server 💖
- 🌸 Number: RFC 5779
- 👩💻 Authors: J. Korhonen (Ed.) from Nokia Siemens Network, J. Bournelle from Orange Labs, K. Chowdhury from Cisco Systems, A. Muhanna from Ericsson, and U. Meyer from RWTH Aachen
- 📜 Category: Standards Track (this is an actual standard, not just an idea 😤)
- 🗓️ Date: February 2010
- 🔢 ISSN: 2070-1721
- 🔁 Obsoletes/Updates: The title block doesn't list anything this one obsoletes or updates, so there's nothing to add there.
It's from the IETF, which is the group that writes the Internet's rulebook 🌈
Abstract 💖
Okay so this spec defines the AAA stuff (Authentication, Authorization, and Accounting) between Proxy Mobile IPv6 entities, meaning both the Mobile Access Gateway and the Local Mobility Anchor, and a AAA server inside a Proxy Mobile IPv6 Domain. The main job of these conversations is downloading and updating a mobile node's policy profile info between those PMIPv6 entities and a remote policy store. It's giving organized 🗂️✨
Status of This Memo 🎀
This is an Internet Standards Track document 📜
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5779 🔗
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please actually read these, bestie, because they explain your rights and restrictions for this document 📋 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 💅
Table of Contents 🦋
1. Introduction ....................................................4
2. Terminology and Abbreviations ...................................4
3. Solution Overview ...............................................5
4. Generic Application Support and Command Codes ...................6
4.1. MAG-to-HAAA Interface ......................................6
4.2. LMA-to-HAAA Interface ......................................7
4.2.1. General Operation and Authorization of PBU ..........7
4.2.2. Updating LMA Address to HAAA ........................8
4.2.3. Mobile Node Address Update and Assignment ...........8
5. Attribute Value Pair Definitions ................................9
5.1. MIP6-Agent-Info AVP ........................................9
5.2. PMIP6-IPv4-Home-Address AVP ...............................10
5.3. MIP6-Home-Link-Prefix AVP .................................10
5.4. PMIP6-DHCP-Server-Address AVP .............................10
5.5. MIP6-Feature-Vector AVP ...................................10
5.6. Mobile-Node-Identifier AVP ................................11
5.7. Calling-Station-Id AVP ....................................12
5.8. Service-Selection AVP .....................................12
5.9. Service-Configuration AVP .................................13
6. Proxy Mobile IPv6 Session Management ...........................13
6.1. Session-Termination-Request ...............................14
6.2. Session-Termination-Answer ................................14
6.3. Abort-Session-Request .....................................14
6.4. Abort-Session-Answer ......................................14
7. Attribute Value Pair Occurrence Tables .........................14
7.1. MAG-to-HAAA Interface .....................................15
7.2. LMA-to-HAAA Interface .....................................15
8. Example Signaling Flows ........................................15
9. IANA Considerations ............................................17
9.1. Attribute Value Pair Codes ................................17
9.2. Namespaces ................................................17
10. Security Considerations .......................................17
11. Acknowledgements ..............................................17
12. References ....................................................18
12.1. Normative References .....................................18
12.2. Informative References ...................................181. Introduction ✨
Okay so this spec defines AAA interactions between a Mobile Access Gateway (MAG) and a AAA server, and between a Local Mobility Anchor (LMA) and a AAA server, all inside a Proxy Mobile IPv6 (PMIPv6) Domain [RFC5213] 🏠 The main purpose is downloading and updating mobile node (MN) specific policy profile info between the PMIPv6 entities (a MAG and an LMA) and a remote policy store. Main character energy for sure 👑
Dynamically assigning and downloading an MN's policy profile to a MAG from a remote policy store is super desirable, because it makes bigger PMIPv6 domains way easier to deploy and maintain 🧚 The same AAA infrastructure already used to authenticate and authorize the MN for network access can be reused to download some or all of the policy info the MAG needs 🔁
Once the network has authenticated the MN, the MAG sends a Proxy Binding Update (PBU) to the LMA to set up a mobility session for the MN 📨 When the LMA gets that PBU, it may need to check the PBU against the AAA infrastructure. That same infrastructure can also be used to update the remote policy store with the mobility session info the LMA provides, which is so efficient, I'm obsessed 😭
In this spec, the home AAA (HAAA) server functionality is co-located with the remote policy store. The NAS functionality may be co-located with the MAG function in the network access router. Diameter [RFC3588] is the AAA protocol being used 💅
2. Terminology and Abbreviations 📖
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 [RFC2119] 🧐
The general terminology in this document comes from [RFC5213] and [NETLMM-PMIP6]. These extra or clarified terms are also used here:
- Network Access Server (NAS): A device that gives a user access to a network 🌐 In this document, the NAS may be built into or co-located with a MAG. The NAS has a Diameter client function.
- Home AAA (HAAA): An Authentication, Authorization, and Accounting (AAA) server located in the user's home network 🏡 Basically, a HAAA is a Diameter server.
3. Solution Overview 🧚
This document covers the AAA interactions and AAA-based session management the PMIPv6 Domain needs 🦋 It defines Diameter-based AAA interactions between the MAG and the HAAA, and between the LMA and the HAAA.
The policy profile gets downloaded from the HAAA to the MAG when the MN attaches to the PMIPv6 Domain. Figure 1 shows the participating network entities. This document focuses on the MAG, the LMA, and the HAAA (the home Diameter server) 🎀
+--------+
| HAAA & | Diameter +-----+
| Policy |<---(2)-->| LMA |
| Store | +-----+
+--------+ | <--- LMA-Address
^ |
| // \\
+---|------------- //---\\----------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+---|-----------//---------\\-------------+
| // \\
Diameter // <- Tunnel1 \\ <- Tunnel2
(1) // \\
| |- MAG1-Address |- MAG2-Address
| +----+ +----+
+---->|MAG1| |MAG2|
+----+ +----+
| |
| |
[MN1] [MN2]Legend:
(1): MAG-to-HAAA interaction is described in Section 7.1
(2): LMA-to-HAAA interaction is described in Section 7.2 Figure 1: Proxy Mobile IPv6 Domain Interaction
with Diameter HAAA ServerUsually, when an MN shows up in a PMIPv6 Domain, a network access authentication procedure kicks off 🔐 Which authentication mechanism gets used depends on the access network deployment, but it could be based on the Extensible Authentication Protocol (EAP) [RFC3748]. During that procedure, the MAG acting as a NAS asks the HAAA through the AAA infrastructure using the Diameter protocol. If the HAAA sees that the subscriber is also authorized for the PMIPv6 service, the PMIPv6-specific info comes back with the successful network access authentication answer to the MAG ✨
Once the MN has been successfully authenticated, the MAG sends a PBU to the LMA based on the MN's policy profile info 📨 When the LMA gets the PBU, it talks to the HAAA and fetches the relevant parts of the subscriber's policy profile and the authorization info for the mobility service session 🫶 In this spec, the HAAA plays the role of the PMIPv6 remote policy store.
4. Generic Application Support and Command Codes 👑
This spec doesn't define new Application-IDs or Command Codes for the MAG-to-HAAA or LMA-to-HAAA Diameter connections 🙅♀️ Instead, it's generic to any Diameter application (and its commands) that's suitable for network access authentication and authorization. Example applications include NASREQ [RFC4005] and EAP [RFC4072] 🌸
4.1. MAG-to-HAAA Interface
okay so the MAG-to-HAAA interactions are mainly for bootstrapping a PMIPv6 mobility service session when an MN attaches and authenticates to a PMIPv6 Domain 💖 That includes bootstrapping the PMIPv6 session-related information ✨. The same interface may also be used for accounting 🧾. The MAG acts as a Diameter client 🎀.
Whenever the MAG sends a Diameter request message to the HAAA, the User-Name AVP SHOULD contain the MN's identity, unless the identity is being suppressed for policy reasons -- for example, when identity hiding is in effect 🙈. The MN identity, if available, MUST be in Network Access Identifier (NAI) [RFC4282] format. At minimum, the home realm of the MN MUST be available at the MAG when the network access authentication takes place. Otherwise the MAG can't route the Diameter request messages to the correct HAAA 💀. The MN identity used on the MAG-to-HAAA interface and in the User-Name AVP MAY be entirely related to the network access authentication, so it might not be suitable to use as the MN-ID mobility option value in the subsequent PBU / Proxy Binding Acknowledgement (PBA) messages 🌸. See the related discussion on MN identities in Sections 4.2 and 5.6.
For session management and service authorization purposes, session state SHOULD be maintained on the MAG-to-HAAA interface. See the discussion in Section 5.8 🧚.
4.2. LMA-to-HAAA Interface
The LMA-to-HAAA interface may be used for multiple purposes ✨. These include authorizing the incoming PBU, updating the LMA address to the HAAA, delegating the assignment of the MN-HNP (home network prefix) or the IPv4-HoA (home address) to the HAAA, and accounting and PMIPv6 session management 💅. The main job of this interface is to update the HAAA with the LMA address information when the LMA is dynamically assigned, and to swap the MN address assignment information between the LMA and the HAAA 🦋.
The LMA-to-HAAA interface description is meant for different types of deployments and architectures 🌈. So this specification only outlines the AVPs and the considerations that the deployment-specific Diameter applications need to keep in mind from the PMIPv6 and LMA's point of view 🫶.
4.2.1. General Operation and Authorization of PBU
Whenever the LMA sends a Diameter request message to the HAAA, the User-Name AVP SHOULD contain the MN's identity. The LMA-provided identity in the User-Name AVP is strongly RECOMMENDED to be the same as the MN's identity information in the PBU MN-ID [RFC4283] [RFC5213] mobility option 👑. The identity SHOULD also be the same as the one used on the MAG-to-HAAA interface. But if those identities differ, the HAAA MUST have a mechanism for mapping the MN identity used on the MAG-to-HAAA interface to the identity used on the LMA-to-HAAA interface 🔥.
If the PBU contains the MN Link-Layer Identifier option, the Calling-Station-Id AVP SHOULD be included in the request message that carries the received link-layer identifier. Also, if the PBU contains the Service Selection mobility option [RFC5149], the Service-Selection AVP SHOULD be included in the request message that carries the received service identifier. Both the MN link-layer identifier and the service selection can give the HAAA more info for the PBU authorization step ✨.
The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY. The Diameter session-related aspects discussed in Section 6 need to be taken into consideration when designing the Diameter application for the LMA-to-HAAA interface 🧚. If the HAAA is not able to authorize the subscriber's mobility service session, then the reply message to the LMA MUST have the Result-Code AVP set to the value DIAMETER_AUTHORIZATION_REJECTED (5003), indicating a permanent failure 💀. A failed authorization obviously results in a rejection of the PBU, and a PBA with an appropriate error Status Value MUST be sent back to the MAG 🙅♀️.
The authorization step MUST be performed at least for the initial PBU session up to a mobility session, when the LMA-to-HAAA interface is deployed 🎀. For the subsequent re-registration and handover PBUs, the authorization step MAY be repeated (in this case, the LMA-to-HAAA interface should also maintain an authorization session state) 🍓.
4.2.2. Updating LMA Address to HAAA
In the case of dynamic LMA discovery and assignment [NETLMM-LMA], the HAAA and the remote policy store may need to be updated with the selected LMA address information 🌈. The update can be done during the PBU authorization step using the LMA-to-HAAA interface. This specification uses the MIP6-Agent-Info AVP and its MIP-Home-Agent-Address and MIP-Home-Agent-Host sub-AVPs to carry the LMA's address information from the LMA to the HAAA 🦋. The LMA address information in the request message MUST contain the IP address of the LMA, or the Fully Qualified Domain Name (FQDN) that uniquely identifies the LMA, or both 💜. The LMA address information refers to the PMIPv6 part of the LMA, not necessarily the LMA part that interfaces with the AAA infrastructure 🧚.
This specification does not define any HAAA-initiated LMA relocation functionality 🙈. So when the MIP6-Agent-Info AVP is included in Diameter answer messages sent from the HAAA to the LMA, the HAAA indicates this by setting the MIP-Home-Agent-Address AVP to the all zeroes address (e.g., 0::0) and not including the MIP-Home-Agent-Host AVP ✨.
4.2.3. Mobile Node Address Update and Assignment
The LMA and the HAAA use the MIP6-Home-Link-Prefix AVP to exchange the MN-HNP when appropriate 💖. In the same way, the LMA and the HAAA use the PMIP6-IPv4-Home-Address AVP to exchange the IPv4-MN-HoA when appropriate 🌸. These AVPs are encapsulated inside the MIP6-Agent-Info AVP. The MN address information exchange is again done during the PBU authorization step. The HAAA MAY also use the LMA-provided MN address information as a part of the information it uses to authorize the PBU 👑.
Which entity is actually responsible for address management is deployment-specific within the PMIPv6 Domain, and it MUST be pre-agreed on a per-deployment basis 🫶. When the LMA is responsible for address management, the MIP6-Agent-Info AVP is used to inform the HAAA and the remote policy store of the MN-HNP/IPv4-MN-HoA assigned to the MN ✨.
It's also possible for the LMA to delegate address management to the HAAA 🦋. In this case, the MN-HNP/IPv4-MN-HoA are set to undefined addresses (as described in Section 5.1) in the Diameter request message sent from the LMA to the HAAA. The LMA expects to receive the HAAA-assigned HNP/IPv4-MN-HoA in the corresponding Diameter answer message 🎀.
5. Attribute Value Pair Definitions 💅
This section describes Attribute Value Pairs (AVPs) that are defined by this specification or re-used from existing specifications in a PMIPv6-specific way 🌈. Derived Diameter AVP Data Formats such as Address and UTF8String are defined in Section 4.3 of [RFC3588]. Grouped AVP values are defined in Section 4.4 of [RFC3588] 🧚.
5.1. MIP6-Agent-Info AVP
The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in [RFC5447] ✨. The AVP is used to carry LMA addressing-related information and an MN-HNP. This specification extends the MIP6-Agent-Info with the PMIP6-IPv4-Home-Address AVP, using the Diameter extensibility rules defined in [RFC3588]. The PMIP6-IPv4-Home-Address AVP contains the IPv4-MN-HoA 💜.
The extended MIP6-Agent-Info AVP results in the following grouped AVP. The grouped AVP has the following modified ABNF (as defined in [RFC3588]) 🍓:
MIP6-Agent-Info ::= < AVP-Header: 486 >
*2[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ]
[ MIP6-Home-Link-Prefix ]
[ PMIP6-IPv4-Home-Address ]
* [ AVP ]If the MIP-Home-Agent-Address is set to the all zeroes address (e.g., 0::0), the receiver of the MIP6-Agent-Info AVP MUST ignore the MIP-Home-Agent-Address AVP 🙅♀️.
5.2. PMIP6-IPv4-Home-Address AVP
The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is of type Address and contains an IPv4 address 🦋. This AVP is used to carry the IPv4-MN-HoA, if available, from the HAAA to the MAG. This AVP SHOULD only be present when the MN is statically provisioned with the IPv4-MN-HoA 💖. Note that proactive dynamic assignment of the IPv4-MN-HoA by the HAAA may result in unnecessary reservation of IPv4 address resources, because the MN may considerably delay or completely bypass its IPv4 address configuration 🙈.
The PMIP6-IPv4-Home-Address AVP is also used on the LMA-to-HAAA interface. The AVP contains the IPv4-MN-HoA assigned to the MN. If the LMA delegates the assignment of the IPv4-MN-HoA to the HAAA, the AVP MUST contain the all zeroes IPv4 address (i.e., 0.0.0.0) in the request message. If the LMA delegated the IPv4-MN-HoA assignment to the HAAA, then the AVP contains the HAAA-assigned IPv4-MN-HoA in the response message 🌸.
5.3. MIP6-Home-Link-Prefix AVP
The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5447] ✨. This AVP is used to carry the MN-HNP, if available, from the HAAA to the MAG. The low 64 bits of the prefix MUST be all zeroes 🧚.
The MIP6-Home-Link-Prefix AVP is also used on the LMA-to-HAAA interface. The AVP contains the prefix assigned to the MN. If the LMA delegates the assignment of the MN-HNP to the HAAA, the AVP MUST contain the all zeroes address (i.e., 0::0) in the request message. If the LMA delegated the MN-HNP assignment to the HAAA, then the AVP contains the HAAA-assigned MN-HNP in the response message 👑.
5.4. PMIP6-DHCP-Server-Address AVP
The PMIP6-DHCP-Server-Address AVP (AVP Code 504) is of type Address and contains the IP address of the Dynamic Host Configuration Protocol (DHCP) server assigned to the MAG serving the newly attached MN 🎀. If the AVP contains a DHCPv4 [RFC2131] server address, then the Address type MUST be IPv4. If the AVP contains a DHCPv6 [RFC3315] server address, then the Address type MUST be IPv6 💅. The HAAA MAY assign a DHCP server to the MAG in deployments where the MAG acts as a DHCP Relay [NETLMM-PMIP6] 🌈.
5.5. MIP6-Feature-Vector AVP 🦋
okay so the MIP6-Feature-Vector AVP was originally defined in [RFC5447], and this doc adds brand new capability flag bits to it, following the IANA rules in RFC 5447 💅
PMIP6_SUPPORTED (0x0000010000000000) 🌸
when the MAG/NAS sets this bit in the MIP6-Feature-Vector AVP, it's telling the HAAA "hey, I support PMIPv6!" 🙌 and when the HAAA sets it in the response MIP6-Feature-Vector AVP, it means the HAAA has PMIPv6 support too. this capability bit can also be used to allow PMIPv6 mobility support at a subscription granularity ✨
IP4_HOA_SUPPORTED (0x0000020000000000) 🍓
assignment of the IPv4-MN-HoA is supported here. when the MAG sets this bit, it means the MAG implements a minimal functionality of a DHCP server (and a relay) and can deliver the IPv4-MN-HoA to the MN. when the HAAA sets this bit in the response MIP6-Feature-Vector AVP, it means the HAAA has authorized the use of IPv4-MN-HoA for the MN. if this bit is unset in the returned MIP6-Feature-Vector AVP, the HAAA does not authorize the configuration of IPv4 address 🙈
LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000) 🧚
this one is about direct routing of IP packets between MNs anchored to the same MAG, which is supported as described in Sections 6.10.3 and 9.2 of [RFC5213]. when a MAG sets this bit, it means routing IP packets between MNs anchored to the same MAG is supported, without reverse tunneling packets via the LMA, and without needing any Route Optimization-related signaling (e.g., the Return Routability Procedure in [RFC3775]) before direct routing. if this bit is cleared in the returned MIP6-Feature-Vector AVP, the HAAA does not authorize direct routing of packets between MNs anchored to the same MAG. the MAG SHOULD support this policy feature on a per-MN and per-subscription basis 💜
the MIP6-Feature-Vector AVP is also used on the LMA-to-HAAA interface, and it's giving capability negotiation! 🤝 using the capability announcement AVP, the LMA and the HAAA can do a simple capability negotiation, and anything that both parties announce is also known to be mutually supported. the capabilities listed in earlier are also supported in the LMA-to-HAAA interface. the LMA-to-HAAA interface does not define any new capability values 🫶
5.6. Mobile-Node-Identifier AVP 🪪
the Mobile-Node-Identifier AVP (AVP Code 506) is of type UTF8String and carries the mobile node identifier (MN-Identifier; see [RFC5213]) in the NAI [RFC4282] format. it's used on the MAG-to-HAAA interface. this AVP is designed for deployments where the MAG has no way to find out a MN identity it could use in later PBU/PBA exchanges (for example, because of identity hiding during network access authentication), or where the HAAA wants to assign periodically changing identities to the MN 🎀
the Mobile-Node-Identifier AVP is returned in the answer message that ends a successful authentication (and possibly authorization) exchange between the MAG and the HAAA, as long as the HAAA is able to provide the MAG with the MN-Identifier in the first place. the MAG MUST use the received MN-Identifier if it hasn't been able to get the mobile node identifier through other means. if the MAG already has a valid mobile node identifier, then the MAG MUST silently discard the received MN-Identifier 🙅♀️
5.7. Calling-Station-Id AVP 📞
the Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and contains a link-layer identifier of the MN. this identifier matches the link-layer identifier defined in RFC 5213, Sections 2.2 and 8.6. the Link-Layer Identifier is encoded in ASCII format (upper case only), with octet values separated by a "-". example: "00-23-32-C9-79-38" 🔢 and the encoding is actually the same as the MAC address encoding in Section 3.21 of RFC 3580. iykyk 😌
5.8. Service-Selection AVP 🛍️
the Service-Selection AVP (AVP Code 493) is of type UTF8String and contains an LMA-provided service identifier on the LMA-to-HAAA interface. it's re-used from [RFC5778]. the service identifier may be used to help the PBU authorization and the assignment of the MN-HNP and the IPv4-MN-HoA, as described in RFC 5149 [RFC5149]. the identifier MUST be unique within the PMIPv6 Domain. if the Service-Selection AVP isn't in the request message, the HAAA may want to tell the LMA about the default service provisioned to the MN and include the Service-Selection AVP in the response message 💭
it's also possible that the MAG gets the service selection information from the MN, for example through some lower layer mechanism. in this case, the MAG MUST include the Service-Selection AVP also in the MAG-to-HAAA request messages. if the Service-Selection AVP is absent from the MAG-to-HAAA request messages, the HAAA may want to tell the MAG about the default service provisioned to the MN and include the Service-Selection AVP in the response message 🎟️
whenever the Service-Selection AVP is included in a request message or a response message, and the AAA interaction with the HAAA completes successfully, it's an indication that the HAAA also authorized the MN to some service. this should be taken into account when deciding what to include in the Auth-Request-Type AVP 👀
the service selection concept supports signaling one service at a time. however, the MN policy profile MAY support multiple services being used simultaneously. for this, the HAAA MAY return multiple LMA and service pairs (see Section 5.9) to the MAG in a response message that ends a successful authentication (and possibly authorization) exchange between the MAG and the HAAA. whenever the MN starts an additional mobility session to another service (using a link layer or deployment specific method), the provisioned service information is already in the MAG, so there's no need for extra AAA signaling between the MAG and the HAAA. main character energy 👑
5.9. Service-Configuration AVP 🗂️
the Service-Configuration AVP (AVP Code 507) is of type Grouped and contains a service and an LMA pair. the HAAA can use this AVP to tell the MAG which services the MN is subscribed to and which LMAs those services are hosted on ✨
Service-Configuration ::= < AVP-Header: 507 >
[ MIP6-Agent-Info ]
[ Service-Selection ]
* [ AVP ]6. Proxy Mobile IPv6 Session Management 🌈
okay this part is about the session life cycle 🔄 concerning a PMIPv6 mobility session, the HAAA, the MAG, and the LMA Diameter entities SHOULD be stateful and maintain the corresponding Authorization Session State Machine defined in [RFC3588]. if a state is maintained, then a PMIPv6 mobility session that can be identified by any of the Binding Cache Entry (BCE) Lookup Keys described in RFC 5213 (see Sections 5.4.1.1, 5.4.1.2, and 5.4.1.3) MUST map to a single Diameter Session-Id. if the PMIPv6 Domain allows further separation of sessions, for example identified by the RFC 5213 BCE Lookup Keys and the service selection combination (see Section 5.8 and [RFC5149]), then a single Diameter Session-Id MUST map to a PMIPv6 mobility session identified by the RFC 5213 BCE Lookup Keys and the selected service 🧩
if both the MAG-to-HAAA and the LMA-to-HAAA interfaces are deployed in a PMIPv6 Domain, and a state is maintained on both interfaces, then one PMIPv6 mobility session would have two distinct Diameter sessions on the HAAA. the HAAA needs to be aware of this deployment possibility and SHOULD allow multiple Diameter sessions for the same PMIPv6 mobility session 🫠
diameter session termination-related commands (the ones in the following sections) may be exchanged between the LMA and the HAAA, or between the MAG and the HAAA. the actual PMIPv6 session termination procedures happen at the PMIPv6 protocol level and are described in more detail in RFC 5213 and [MEXT-BINDING] 🛑
6.1. Session-Termination-Request 🚪
the LMA or the MAG MAY send the Session-Termination-Request (STR) command [RFC3588] to let the HAAA know that the termination of an ongoing PMIPv6 session is in progress 🏁
6.2. Session-Termination-Answer ✅
the Session-Termination-Answer (STA) [RFC3588] is sent by the HAAA to acknowledge the termination of a PMIPv6 session. bestie, that's the receipt 🧾
6.3. Abort-Session-Request 🚨
the HAAA MAY send the Abort-Session-Request (ASR) command [RFC3588] to the LMA or to the MAG and request termination of a PMIPv6 session. this is the HAAA being the plot twist 😭
6.4. Abort-Session-Answer 🫡
the Abort-Session-Answer (ASA) command [RFC3588] is sent by the LMA or the MAG to acknowledge the termination of a PMIPv6 session 💖
7. Attribute Value Pair Occurrence Tables 📊
the following tables list the PMIPv6 MAG-to-HAAA interface and LMA-to-HAAA interface AVPs, including the ones defined in [RFC5447] 🔍
Figure 2 contains the AVPs and their occurrences on the MAG-to-HAAA interface. the AVPs that are part of a grouped AVP aren't listed in the table, only the grouped AVP is listed 🧁
7.1. MAG-to-HAAA Interface 🛰️
+---------------+
| Command-Code |
|-------+-------+
Attribute Name | REQ | ANS |
-------------------------------+-------+-------+
PMIP6-DHCP-Server-Address | 0 | 0+ |
MIP6-Agent-Info | 0+ | 0+ |
MIP6-Feature-Vector | 0-1 | 0-1 |
Mobile-Node-Identifier | 0-1 | 0-1 |
Calling-Station-Id | 0-1 | 0 |
Service-Selection | 0-1 | 0 |
Service-Configuration | 0 | 0+ |
+-------+-------+
Figure 2: MAG-to-HAAA Interface Generic Diameter Request
and Answer Commands AVPs7.2. LMA-to-HAAA Interface 🌷
+---------------+
| Command-Code |
|-------+-------+
Attribute Name | REQ | ANS |
-------------------------------+-------+-------+
MIP6-Agent-Info | 0-1 | 0-1 |
MIP6-Feature-Vector | 0-1 | 0-1 |
Calling-Station-Id | 0-1 | 0 |
Service-Selection | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 |
+-------+-------+
Figure 3: LMA-to-HAAA Interface Generic Diameter Request
and Answer Commands AVPs8. Example Signaling Flows ✨
okay so bestie, here's the whole PMIPv6 bootstrapping story in one picture 🎀 Figure 4 shows a signaling flow example during PMIPv6 bootstrapping using the AAA interactions defined in this spec. In step (1), the MN gets authenticated to the PMIPv6 Domain using EAP-based authentication 🔐. The MAG-to-HAAA signaling uses the Diameter EAP Application. Then in step (2), the LMA uses the Diameter NASREQ application to authorize the MN with the HAAA server 💜
The MAG-to-HAAA AVPs (listed in Section 7.1) are used during step (1). They only show up in the Diameter EAP Request (DER) message that starts the EAP exchange, and in the Diameter EAP Answer (DEA) message that successfully finishes it 🦋 The LMA-to-HAAA AVPs (listed in Section 7.2) are used during step (2). That step is what authorizes the MN's request for the mobility service and updates the HAAA server with the LMA info that got assigned. Lowkey the best part: this step may also dynamically help with assigning the MN-HNP 🧚
MN MAG/NAS LMA HAAA
| | | |
| L2 attach | | |
|-------------------->| | |
| EAP/req-identity | | |
|<--------------------| | |
| EAP/res-identity | DER + MAG-to-HAAA AVPs | s
|-------------------->|---------------------------------------->| t
| EAP/req #1 | DEA (EAP request #1) | e
|<--------------------|<----------------------------------------| p
| EAP/res #2 | DER (EAP response #2) |
|-------------------->|---------------------------------------->| 1
: : : :
: : : :
| EAP/res #N | DER (EAP response #N) |
|-------------------->|---------------------------------------->|
| EAP/success | DEA (EAP success) + MAG-to-HAAA AVPs |
|<--------------------|<----------------------------------------|
: : : :
: : : :
| | PMIPv6 PBU | AAR + | s
| |------------------->| LMA-to-HAAA AVPs | t
| | |------------------->| e
| | | AAA + | p
| | | LMA-to-HAAA AVPs |
| | PMIPv6 PBA |<-------------------| 2
| RA |<-------------------| |
|<--------------------| | |
: : : :
: : : :
| IP connectivity | PMIPv6 tunnel up | |
|---------------------|====================| |
| | | |
Figure 4: MAG and LMA Signaling Interaction with AAA Server
during PMIPv6 Bootstrapping9. IANA Considerations 🌸
9.1. Attribute Value Pair Codes
okay so IANA, this is the list of brand-new AVPs this spec defines 💅 Here they are with their codes:
PMIP6-DHCP-Server-Address 504
PMIP6-IPv4-Home-Address 505
Mobile-Node-Identifier 506
Service-Configuration 5079.2. Namespaces
this spec adds new values to the Mobility Capability registry (see [RFC5447]) for use with the MIP6-Feature-Vector AVP ✨ Here's the table, all three rows, each one tagged with [RFC5779]:
Token | Value | Description
---------------------------------+----------------------+------------
PMIP6_SUPPORTED | 0x0000010000000000 | [RFC5779]
IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC5779]
LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC5779]10. Security Considerations 🔥
⚠️ bestie, this part is serious. Don't skip it.
the security considerations of the Diameter Base protocol [RFC3588], the Diameter EAP application [RFC4072], the Diameter NASREQ application [RFC4005], and Diameter Mobile IPv6 integrated scenario bootstrapping [RFC5447] are all applicable to this document 🔐
In general, the Diameter messages may be transported between the LMA and the Diameter server via one or more AAA brokers or Diameter agents 🦋 In that case, the LMA-to-Diameter-server AAA communication relies on the security properties of the intermediate AAA brokers and Diameter agents (such as proxies). So basically the chain is only as strong as its weakest middleman 💀
11. Acknowledgements 🫶
Jouni Korhonen would like to thank the TEKES GIGA program MERCoNe-project for providing funding to work on this document while he was with TeliaSonera 💖 The authors also thank Pasi Eronen, Peter McCann, Spencer Dawkins, and Marco Liebsch for their detailed reviews of this document. Iconic reviewers, honestly 👑
12. References 📚
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
- [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
- [RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010.
12.2. Informative References
- [MEXT-BINDING] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", Work in Progress, October 2009.
- [NETLMM-LMA] Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy Mobile IPv6", Work in Progress, September 2009.
- [NETLMM-PMIP6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", Work in Progress, September 2009.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
- [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
Authors' Addresses 🦋
Jouni Korhonen (editor) Nokia Siemens Network Linnoitustie 6 Espoo FI-02600 Finland
EMail: jouni.nospam@gmail.com
Julien Bournelle Orange Labs 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France
EMail: julien.bournelle@orange-ftgroup.com
Kuntal Chowdhury Cisco Systems 30 International Place Tewksbury, MA 01876 USA
EMail: kchowdhury@cisco.com
Ahmad Muhanna Ericsson, Inc. 2201 Lakeside Blvd. Richardson, TX 75082 USA
EMail: Ahmad.muhanna@ericsson.com
Ulrike Meyer RWTH Aachen
EMail: meyer@umic.rwth-aachen.de
📦 where this page comes from
- ietf: rfc5779 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms