RFC 7156
Diameter Support for Proxy Mobile IPv6 Localized Routing
Diameter Support for Proxy Mobile IPv6 Localized Routing ✨
RFC 7156 🎀 is the spec, written by G. Zorn (Network Zen), Q. Wu (Huawei), and J. Korhonen (Broadcom). It's an IETF Standards Track doc 💅, published in April 2014, with ISSN 2070-1721. It's part of the IETF's Internet Engineering Task Force crew 🌈.
Abstract
Okay so in Proxy Mobile IPv6 🦋, packets coming from a Mobile Node (MN) usually get tunneled by the Mobile Access Gateway (MAG) it's attached to over to a Local Mobility Anchor (LMA) for routing. "Localized routing" is when packets skip the LMA entirely and go straight between the MN's MAG and the MAG of its Correspondent Node (CN) 🚀. In a PMIPv6 setup, you might want to control whether those localized routing sessions between two MAGs can happen at all, by requiring that each one gets authorized first 🔐. This doc explains how to do that with the Diameter protocol 💜.
Status of This Memo 📜
This is an Internet Standards Track document 🌸.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. More info on Internet Standards is in Section 2 of RFC 5741 📚.
You can check the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7156 🔗.
Copyright Notice ©️
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully 👀, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 📝.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Attribute Value Pair Used in This Document . . . . . . . . . 4
4.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 5
4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 5
4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 5
4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 5
5. Example Signaling Flows for Localized Routing Service
Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 111. Introduction 🌷
Proxy Mobile IPv6 (PMIPv6) [RFC5213] lets the Mobile Access Gateway (MAG) optimize media delivery 🎬. It does this by locally routing packets from a Mobile Node (MN) to a Correspondent Node (CN) that's attached to an access link on the same Mobile Access Gateway, so those packets never get tunneled to the Mobile Node's Local Mobility Anchor (LMA) 🙌. RFC 5213 [RFC5213] calls this "local routing" 🏠. The catch is that this mechanism doesn't work for the usual setups, where the MN and CN are on different MAGs and are registered with the same LMA or different LMAs 🙈.
[RFC6279] covers those usual setups 🧠. It defines the problem statement for PMIPv6 localized routing. Based on scenarios A11, A12, and A21 from [RFC6279], [RFC6705] specifies the PMIPv6 localized routing protocol 🦋. That protocol sets up a localized routing path between two Mobile Access Gateways in a PMIPv6 domain ✨.
This document adds Authentication, Authorization, and Accounting (AAA) support using Diameter [RFC6733] 💅. It covers the authorization procedure between the PMIPv6 mobility entities (MAG or LMA) and an AAA server inside a Proxy Mobile IPv6 domain, for localized routing in scenarios A11, A12, and A21 from [RFC6279] 🫶.
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.
3. Solution Overview 🧩
Here's the tea 🍵. This doc explains how to give authorization info to the Mobile Node's MAG or LMA so localized routing can happen, and how to resolve the destination MN's MAG, through a chat between the LMA and the AAA server 💬. Figure 1 shows the reference architecture for Localized Routing Service Authorization. This architecture assumes the following:
- If the MN and CN belong to different LMAs, the MN and CN should share the same MAG (that's scenario A12 from [RFC6279]) 💕. For example, MN1 and CN2 in Figure 1 are attached to MAG1 and belong to LMA1 and LMA2, respectively. Also, LMA1 and LMA2 in Figure 1 are in the same provider domain (as described in [RFC6279]) 🏢.
- If the MN and CN are attached to different MAGs, the MN and CN should belong to the same LMA (that's scenario A21 from [RFC6279]) 🌈. For example, MN1 and CN3 in Figure 1 are attached to MAG1 and MAG3, respectively, but both belong to LMA1 ✨.
- The MN and CN may belong to the same LMA and may be attached to the same MAG (that's scenario A11 from [RFC6279]) 🍓. For example, MN1 and CN1 in Figure 1 are both attached to MAG1 and belong to LMA1 🧚.
- The MAG and LMA support Diameter client functionality 💻.
+---------+
+---------------------->| AAA & |
| +------>| Policy |
| | | Profile |
| Diameter +---------+
| |
| +--V-+ +----+
| +------->|LMA1| |LMA2|
| | +---++ +----+
| | | | |
Diameter | | +-------+---------
| | | | |
| PMIP | | \\
| | // // \\
| | // // \\
| | // // \\
| | | | |
| +---->+---------------+ +----+
| | MAG1 | |MAG3|
+-------->+---------------+ +----+
: : : :
+---+ +---+ +---+ +---+
|MN1| |CN1| |CN2| |CN3|
+---+ +---+ +---+ +---+
Figure 1: Localized Routing Service Authorization Reference
ArchitectureThe MAG and LMA talk to the AAA server following the extension in this document, and that's how the localized routing service gets authorized 🔐🎀.
4. Attribute Value Pair Used in This Document 🎁
This section covers the Attribute Value Pairs (AVPs) and AVP values that this spec defines, or reuses from existing specs in a PMIPv6-specific way 💖.
4.1. User-Name AVP 🙋♀️
The User-Name AVP (AVP Code 1) is defined in [RFC6733], Section 8.14 ✨. It carries the Mobile Node identifier (MN-Identifier) [RFC5213] inside the Diameter AA-Request message [RFC7155] that gets sent to the AAA server 📨. The MN-Identifier itself is defined in PMIPv6 [RFC5213] 🌸.
4.2. PMIP6-IPv4-Home-Address AVP 🏡
The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in [RFC5779], Section 5.2 🌟. It carries the Mobile Node's IPv4 home address (IPv4-MN-HoA) in the Diameter AA-Request message [RFC7155] sent to the AAA server 💌. The IPv4-MN-HoA is defined in [RFC5844] 🦋.
4.3. MIP6-Home-Link-Prefix AVP 🛣️
The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779], Section 5.3 💜. It carries the Mobile Node's home network prefix (MN-HNP) in the Diameter AA-Request [RFC7155] sent to the AAA server 🫶.
4.4. MIP6-Feature-Vector AVP 🚩
The MIP6-Feature-Vector AVP is defined in [RFC5447] 📘. It holds a 64-bit flags field that tells the AAA server which capabilities are supported 💅. This document allocates a new capability flag bit, following the IANA rules in RFC 5447 [RFC5447] 🎀.
INTER_MAG_ROUTING_SUPPORTED (0x0002000000000000)When this flag is set, it means direct routing of IP packets between MNs anchored to different MAGs, without involving any LMA, is supported or authorized 🌈.
During the network access authentication and authorization procedure [RFC5779] 🔑, the MAG or LMA sets this flag in the MIP6-Feature-Vector AVP that goes in the request. That tells the home AAA server (HAAA) that inter-MAG direct routing may be provided to the mobile node identified by the User-Name AVP 🏠. When the HAAA sets the INTER_MAG_ROUTING_SUPPORTED flag in the response, it's telling the MAG or LMA that direct routing of IP packets between this mobile node and another node anchored to a different MAG is authorized 🎉. The MAG and the LMA also set the INTER_MAG_ROUTING_SUPPORTED flag in the MIP6-Feature-Vector AVP of the AA-R sent to the HAAA, to ask for authorization of inter-MAG direct routing between the mobile nodes identified by two distinct instances of the User-Name AVP 💫. If this bit is set in the returned MIP6-Feature-Vector AVP, the HAAA authorizes direct routing of packets between MNs anchored to different MAGs ⭐. When the INTER_MAG_ROUTING_SUPPORTED flag is cleared, whether in the request or the response, it means the procedures for authorizing localized routing between MNs anchored to different MAGs aren't supported or aren't authorized 🙈.
MAG and LMA that comply with this specification MUST support this policy feature on a per-MN and per-subscription basis. 🌈👑
Part 1 of 3 is done, bestie! 🦋 Section 5 (the signaling flows) is up next, so stay tuned 💖.
5. Example Signaling Flows for Localized Routing Service Authorization ✨
okay so, localized routing service authorization can happen during the network access authentication procedure [RFC5779] before localized routing even gets switched on 🎀 in that case, the preauthorized pairs of LMA / prefix sets can be downloaded to Proxy Mobile IPv6 entities during the procedure from [RFC5779]. then localized routing can kick off once the destination of a received packet matches one or more of the prefixes received during that procedure from [RFC5779] 💖
Figure 2 shows an example scenario where MAG1 acts as a Diameter client 💅 it processes the data packet from MN1 to MN2 and requests authorization of localized routing (aka MAG-Initiated LR authorization). in this scenario, MN1 and MN2 are attached to the same MAG but anchored to different LMAs (scenario A12 described in [RFC6279]). so MAG1 knows that MN2 belongs to a different LMA. (it can figure that out by looking up the binding cache entries for MN1 and MN2 and comparing the addresses of LMA1 and LMA2 🧚) to set up a localized routing path with MAG2, MAG1 acts as a Diameter client and sends an AA-Request message to the AAA server. the message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set, plus two instances of the User-Name AVP [RFC6733] holding the identifiers of MN1 and MN2. on top of that, the message may contain either:
- an instance of the MIP6-Home-Link-Prefix AVP [RFC5779] carrying the MN1's IPv4 address;
- an instance of the PMIP6-IPv4-Home-Address AVP [RFC5779] carrying the MN1's home network prefix (MN-HNP).
the AAA server authorizes the localized routing service by checking whether MN1 and MN2 are allowed to use localized routing 👑 if they are, the AAA server responds with an AAA message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set. that means direct routing of IP packets between MNs anchored to the same MAG is authorized ✨ now MAG1 knows localized routing between MN1 and MN2 is allowed! then MAG1 sends the Request messages to LMA1 and LMA2, respectively. that request message is the Localized Routing Initialization (LRI) message in Figure 2 and it belongs to the Initial phase of localized routing. LMA1 and LMA2 respond to MAG1 with the Localized Routing Acknowledge message (LRA in Figure 2) in accordance with [RFC6705] 🦋
in case of LRA_WAIT_TIME expiration [RFC6705], MAG1 should ask for authorization of localized routing again using the procedure described above, before the LRI is retransmitted, up to a maximum of LRI_RETRIES 🙈
+---+ +---+ +----+ +----+ +---+ +----+
|MN2| |MN1| |MAG1| |LMA1| |AAA| |LMA2|
+-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+
| | Anchored | | |
o-----------------------------------------------o
| | Anchored | | |
| o------------------o | |
| Data[MN1->MN2] | | |
| |------->| | | |
| | | AA-Request(MFV, MN1,MN2) |
| | |--------------------> | |
| | | AA-Answer(MFV) | |
| | |<-------------------- | |
| | | LRI | | |
| | |-------->| | |
| | | | LRI | |
| | |----------------------------->|
| | | LRA | | |
| | |<--------| | |
| | | | LRA | |
| | |<-----------------------------|Figure 2: MAG-Initiated Localized Routing Authorization in A12
Figure 3 is the second example scenario 🌸 this time LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting authorization of localized routing. here MN1 and MN2 are attached to a different MAG and anchored to the same LMA (scenario A21 described in [RFC6279]). the LMA knows MN1 and MN2 belong to the same LMA (it can check the binding cache entries for MN1 and MN2 and compare the addresses of the LMA corresponding to MN1 and the LMA corresponding to MN2). unlike the flow in Figure 2, it's LMA1 instead of MAG1 that starts setting up the localized routing path ✨
the Diameter client in LMA1 sends an AA-Request message to the AAA server. the message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set, which says direct routing of IP packets between MNs anchored to different MAGs is supported, plus two instances of the User-Name AVP [RFC6733] containing the identifiers of MN1 and MN2. the AAA server authorizes the localized routing service by checking whether MN1 and MN2 are allowed to use localized routing. if so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set, meaning direct routing of IP packets between MNs anchored to different MAGs is authorized. LMA1 then knows localized routing is allowed 🔥 in a successful case, LMA1 responds to MAG1 in accordance with [RFC6705].
in the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again using the procedure described above, before the LRI is retransmitted, up to a maximum of LRI_RETRIES 😭
+---+ +----+ +----+ +---+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+
| | | Anchored | |
| Anchored o-------------------+--------o
o--------+-------o Data[MN2->MN1] | |
| | |<----- | | |
| | |AA-Request(MFV,MN1,MN2) |
| | |--------->| | |
| | |AA-Answer(MFV) | |
| | LRI |<---------| | |
| |<------| LRI | |
| | LRA |------------------>| |
| |------>| LRA | |
| | |<------------------| |Figure 3: LMA-Initiated Localized Routing Authorization in A21
Figure 4 shows another example scenario 💜 LMA1 acts as a Diameter client again, processing the data packet from MN2 to MN1 and requesting authorization of localized routing. this time MN1 and MN2 are attached to the same MAG and anchored to the same LMA (scenario A11 described in [RFC6279]). the LMA knows MN1 and MN2 belong to the same LMA (it can work that out by looking up the binding cache entries for MN1 and MN2 and comparing the addresses of the LMA corresponding to MN1 and the LMA corresponding to MN2).
the Diameter client in LMA1 sends an AA-Request message to the AAA server. the message contains an instance of the MIP6-Feature-Vector AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit set, plus two instances of the User-Name AVP [RFC6733] containing the identifiers MN1 and MN2. the AAA server authorizes the localized routing service by checking whether MN1 and MN2 are allowed to use localized routing. if so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set, meaning direct routing of IP packets between MNs anchored to the same MAG is authorized. LMA1 then knows localized routing is allowed and responds to MAG1 for localized routing in accordance with [RFC6705] 🦋
in the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again using the procedure described above, before the LRI is retransmitted, up to a maximum of LRI_RETRIES 🫶
+---+ +---+ +----+ +----+ +---+
|MN2| |MN1| |MAG1| |LMA1| |AAA|
+-+-+ +-+-+ +-+--+ +-+--+ +-|-+
| | Anchored | |
o-----------------------o |
| | Anchored | |
| o--------+-------o Data[MN2->MN1]
| | | |<----- |
| | | |AA-Request(MFV,MN1,MN2)
| | | |--------->|
| | | |AA-Answer(MFV)
| | | LRI |<---------|
| | |<------| |
| | | LRA | |
| | |------>| |Figure 4: LMA-Initiated Localized Routing Authorization in A11
6. Security Considerations 🔐
okay bestie, this part is SERIOUS 😭 the security considerations for the Diameter Network Access Server Requirements (NASREQ) [RFC7155] and Diameter Proxy Mobile IPv6 [RFC5779] applications also apply to this document.
the service authorization that the MAG or the LMA asks for relies on the existing trust relationship between the MAG/LMA and the AAA server 🔥
an authorized MAG could, in principle, track the movement of any participating mobile nodes at the level of the MAG they're anchored to. if that MAG were compromised, or under the control of a bad actor, then that tracking could be a privacy breach for the set of tracked mobile nodes 💀 in that case, the traffic pattern from the compromised MAG might be notable, so monitoring for, e.g., excessive queries from MAGs might be worthwhile.
7. IANA Considerations 🧚
this spec defines a new value in the "Mobility Capability Registry" [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (see Section 4.4) ✨
8. Contributors 🎀
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document 🫶
9. Acknowledgements 💖
the authors would like to thank Lionel Morand, Marco Liebsch, Carlos Jesus Bernardos Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms, Stephen Farrel, Robert Sparks, Benoit Claise, and Abhay Roy for their valuable comments and suggestions on this document 🌈
10. References 📚
10.1. Normative References
Okay bestie, these are the must-read refs 📚✨ Everything below is stuff the spec leans on, so you need it to understand the rest.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑[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. 💅[RFC5779]Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010. 🎀[RFC5844]Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 🦋[RFC6705]Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012. 🧚[RFC6733]Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 👑[RFC7155]Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, April 2014. 💜
10.2. Informative References
These ones are more of a "nice to know" vibe, but honestly they're iconic for background 🌈
[RFC6279]Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011. ⭐
Authors' Addresses
Meet the squad who made this happen 🫶 Their contact details are below, exactly as written:
Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-040-4617
EMail: glenzorn@gmail.comQin Wu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Phone: +86-25-56623633
EMail: bill.wu@huawei.comJouni Korhonen
Broadcom
Porkkalankatu 24
FIN-00180 Helsinki
Finland
EMail: jouni.nospam@gmail.com📦 where this page comes from
- ietf: rfc7156 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms