RFC 6705
Localized Routing for Proxy Mobile IPv6
RFC 6705: Localized Routing for Proxy Mobile IPv6 🎀
okay bestie, this one is from September 2012 and it's an IETF Standards Track doc 🦋 (so it's a real spec people are expected to implement, not just vibes). The ISSN is 2070-1721. The authors are S. Krishnan (Ericsson), R. Koodli (Cisco Systems), P. Loureiro (NEC), Q. Wu (Huawei), and A. Dutta (NIKSUN). The title block doesn't list any RFCs that this one obsoletes or updates, so it's standing on its own 💅
Abstract
okay so Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol 🌸 It gives a host IP mobility without the host having to take part in any mobility-related signaling. The catch? PMIPv6 sends all communications through the local mobility anchor, and that can be kinda suboptimal 🙈
Enter Localized Routing (LR) ✨ It lets Mobile Nodes (MNs) that are attached to the same or different Mobile Access Gateways (MAGs) route their traffic using localized forwarding or a direct tunnel between the gateways. This doc proposes how localized routing gets started, how it gets used, and how it gets shut down, all inside a PMIPv6 domain. It also defines two new signaling messages, the Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), which make the whole thing work 🧚
Status of This Memo
This is an Internet Standards Track document 💜
This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6705 🔥
Copyright Notice
Copyright (c) 2012 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 were in effect on the date of publication. Please read these 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, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Initiation of Localized Routing .................................3
3.1. MAG Behavior ...............................................4
3.2. LMA Behavior ...............................................4
4. Teardown of Localized Routing ...................................4
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
5.1. Handover Considerations ....................................6
6. Scenario A21: Two MNs Attached to Different MAGs but the
Same LMA ........................................................7
6.1. Handover Considerations ....................................9
6.2. Tunneling between the MAGs .................................9
7. Scenario A12: Two MNs Attached to the Same MAG with
Different LMAs .................................................10
7.1. Handover Considerations ...................................12
8. Scenario A22: Two MNs Attached to Different MAGs with
Different LMAs .................................................13
9. IPv4 Support in Localized Routing ..............................13
10. Message Formats ...............................................13
10.1. Localized Routing Initiation (LRI) .......................14
10.2. Localized Routing Acknowledgment (LRA) ...................15
11. New Mobility Option ...........................................16
11.1. MAG IPv6 Address .........................................16
12. Configuration Variables .......................................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
15. Contributors ..................................................18
16. Acknowledgments ...............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................191. Introduction ✨
okay so Proxy Mobile IPv6 [RFC5213] is the protocol that keeps a Mobile Node reachable and keeps its sessions alive 🦋 The best part is that the MN doesn't have to explicitly take part in signaling at the Internet Protocol (IP) layer. The network handles all of it 💖
To make that work, PMIPv6 defines a Mobile Access Gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC6275] signaling. It also defines the Local Mobility Anchor (LMA), which behaves kinda like a Home Agent. The LMA and the MAG set up a bidirectional tunnel that carries all the data traffic for the Mobile Nodes 🌸
Here's the tea ☕ When both endpoints live in the same PMIPv6 domain, that tunnel can be suboptimal. It can mean more delay, more congestion in the network, higher transport costs, and extra traffic load on the LMA 🙈
So to fix this, localized routing lets nodes attached to the same or different MAGs swap traffic directly, using localized forwarding or a direct tunnel between the gateways 🧚 [RFC6279] is where the problem statement for PMIPv6 localized routing lives. This document is the solution for localized routing between two MNs in the same PMIPv6 domain 💅
The protocol here assumes that each MN is attached to a MAG, and that each MN's MAG has set up a binding for that MN at its selected LMA, following [RFC5213]. The whole thing is built on the scenarios defined in [RFC6279] ✨
2. Conventions Used in This Document 📚
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] 💜
This document also uses the terminology defined in Section 2 of [RFC6279] 🫶
3. Initiation of Localized Routing 🦋
Since the traffic that's getting localized goes through both the LMA and the MAGs, it's possible (at least in some scenarios) for either of them to start Localized Routing (LR) 👑 To avoid any confusion, the protocol in this document picks the initiator of LR using the rules below 💅
3.1. MAG Behavior
The MAG MUST initiate LR if both of the communicating MNs are attached to it and the MNs are anchored at different LMAs. The MAG MUST NOT initiate LR in any other case 🌈
3.2. LMA Behavior
The LMA MUST initiate LR if both of the communicating MNs are anchored to it. The LMA MUST NOT initiate LR in any other case ⭐
4. Teardown of Localized Routing 🍓
Localized routing is not forever, bestie 🥺 It has a defined lifetime that the initiator sets, and when that lifetime expires, the forwarding MUST revert to using bidirectional tunneling 💀 When localized routing stops, the corresponding Localized Routing Entries (LREs) MUST be removed 🧹
And if the initiator of LR wants to end localized routing before the lifetime in the LRI message runs out, it MUST do that by sending a new LRI message with the lifetime set to zero 🙅♀️✨
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ✨
okay so in this scenario, the two Mobile Nodes chatting with each other are both hanging out on a single MAG, and both have the same LMA as their anchor 🌸 picture it like two besties sitting at the same café table, no need to go all the way to the bakery down the street 🧁
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1so the LMA kicks off a localized routing session by spotting traffic between two MNs that are on the same MAG 👀 the exact way it spots that traffic is NOT nailed down in this document, so implementations and specific deployments get to pick their own vibe 💅 one example is an application-layer signaling entity noticing that localized routing is possible and tipping off the LMA about the two endpoints, and then the LMA checks and realizes they're both on the same MAG ✨ this kind of trigger gives you localized routing at the level of a single application session, which is super flexible 🦋 it's also possible for one of the mobility entities (LMA or MAG) to decide to start localized routing based on configured policy 🎀 heads up though: a MAG following this spec will NOT dynamically start LR in the same LMA case (aka by sending an LRI) 🙈 it can only start LR statically, using the EnableMAGLocalRouting configuration variable from [RFC5213] 💜
+----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |LMA |
+----+ +----+ +----+ +----+
| | | |
| data | data |
|<--------------------->|<------------->|
| | | |
| | data | data |
| |<--------->|<------------->|
| | | LR decision
| | | LRI(Opt1) |
| | |<--------------|
| | | |
| | | LRA(Opt2) |
| | |-------------->|
| | | |
| data | |
|<--------------------->| |
| | | |
| | data | |
| |<--------->| |
| | | |
| | | |
Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
Figure 2once the LMA has noticed the localized routing possibility, it SHOULD build an LRI message 🎀 that's how it signals "hey, I want to start localized routing" and passes along the parameters for it ✨ the LRI is a Mobility Header message, and it MUST include the MN-Identifier (MN-ID) and the Home Network Prefix (HNP) for each of the MNs involved, carried as Mobility Header options 💖 the LMA then MUST send that LRI to the MAG (MAG1) where both MNs are attached 🧚 the whole LR setup is shown in Figure 2 above, so you can see it play out step by step 📸
the MAG (MAG1) MUST check the attachment status of the two MNs locally by looking at the binding cache 🔍 then it MUST check whether the EnableMAGLocalRouting flag is set to 1 🌈 if it isn't, that means the MAG hasn't been set up to allow localized routing 💀 so it MUST reject the LRI and MUST send back an LRA with the Status code "Localized Routing Not Allowed" 🙅♀️ quick note: this doesn't change anything in [RFC5213]. It's just the MAG carrying out the LMA enforcement that's described in Section 6.10.3 of [RFC5213] 🫶 if the MAG IS set up to allow localized routing, it MUST then create LREs for each direction of the communication between the two MNs 🦋 the exact form of those forwarding entries is up to the implementations 🎀 but they SHOULD include the HNP that matches the destination IP address, plus a next-hop identifier (for example, the layer-2 address of the next hop) ✨ those LREs MUST override the Binding Update List (BUL) entries for the specific HNPs listed in the LRI message 👑 which means all the traffic matching those HNPs gets forwarded locally, no detour needed 🏃♀️💨
If the MAG can't deliver packets using the LREs, one of the MNs might have already left the MAG 😭 so the MAG MUST fall back to using the BUL entry, and the LMA MUST forward the received packets using its Binding Cache Entry (BCE). Safety net, bestie 🫶
after it processes the LRI, the MAG MUST respond with a Local Routing Acknowledgment (LRA) message 💌 this Mobility Header message MUST also include the MN-ID and the HNP for each of the communicating MNs, plus an appropriate Status code that tells everyone how the LRI went 📋 Status code 0 means the MAG successfully offered localized routing 🥳 any other value tells you why it couldn't offer the service 🙈 when the Status code is 0, the LMA sets a flag in the BCE for the HNPs, so it knows localized routing is in progress for that HNP 🌸
5.1. Handover Considerations
so what if one of the MNs, let's say MN1, leaves the MAG and attaches to a different MAG (let's call it nMAG)? then the localized routing state has to be set up again 😤 when the LMA gets the PBU from nMAG for MN1, it sees that localized routing is active for MN1 👀 the LMA MUST therefore initiate LR at nMAG and update the LR state of pMAG 🔄 once the handover is done, the LR setup looks like Scenario A21 💅 and the pMAG MUST follow the forwarding rules in Section 6.10.5 of [RFC5213] and decide that it won't do LR for MN1 anymore 🧚
6. Scenario A21: Two MNs Attached to Different MAGs but the Same LMA 🦋
the LMA is allowed to support local forwarding for Mobile Nodes that are attached to two different MAGs inside a single PMIPv6 domain 🌍 it's giving "same LMA, different cafés" 💖
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
+----+-----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 3same as before, the LMA starts LR because of some trigger mechanism 🎀 in this case though, it MUST send two separate LRI messages, one to each MAG 💌 on top of the MN-ID and HNP options, each LRI message MUST also carry the IP address of the other MAG (the counterpart MAG) 🫶 when the MAG IP address option is there, each MAG MUST create a local forwarding entry so that packets for the MN on the remote MAG get sent through a tunnel tied to that remote MAG 🚇 the tunnel between the MAGs is assumed to be set up following the considerations in Section 6.2 ✨
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |LMA |
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data |
|<--------------------->|<----------------------->|
| | | | |
| | data | data |
| |<--------------------->|<----------->|
| | | | |
| | | | |
| | | LRI(Opt1) |
| | |<------------------------|
| | | | |
| | | | LRI(Opt2) |
| | | |<------------|
| | | | |
| | | LRA(Opt3) |
| | |------------------------>|
| | | | |
| | | | LRA(Opt4) |
| | | |------------>|
| | | | |
| | | | |
| | | | |
| data | data | |
|<--------------------->|<--------->| |
| | | | |
| | data | |
| |<--------------------->| |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address
where U is the flag defined in Section 10.2.
Figure 4in this setup, each MAG answers the LRI with an LRA message 📨 after that, all the packets get routed between the MAGs locally, without going through the LMA at all 🏃♀️💨 now here's the tea ☕ if one MAG (say MAG1) sends back a successful LRA (Status value is zero) and the other (say MAG2) sends back an error (Status value is non-zero), LR still happens in one direction (MN1->MAG1->MAG2->MN2) 🎀 but the packets going the other way take the LMA path (MN2->MAG2->LMA->MAG1->MN1) 😅 messy but still works, bestie 🫶
the protocol does NOT need any synchronization between the MAGs before local forwarding starts 🙅♀️ each MAG kicks off its local forwarding independently of the other 💖 no sync is needed because each MAG initiates LR in just one direction 🧚 after the LMA tells MAG1 to start LR, packets from MN1 to MN2 take the path MN1->MAG1->MAG2->MN2, while packets from MN2 to MN1 still take MN2->MAG2->LMA->MAG1->MN1 until the LMA tells MAG2 to start LR too 🔄 and a MAG only ever forwards a packet toward either another MAG or its own LMA, so there's no duplication of packets 🙌 no double delivery, no drama ✨
6.1. Handover Considerations
so if one of the MNs, say MN1, leaves its current MAG (here that's MAG1) and attaches to another MAG (say nMAG1), the localized routing state needs to be set up again 🔄 when the LMA gets the PBU from nMAG1 for MN1, it sees that localized routing is active for MN1 👀 the LMA MUST then initiate LR at nMAG1 and update the LR state of MAG2 so it uses nMAG1 instead of MAG1 💅🎀
6.2. Tunneling between the MAGs 🎀
Okay so for localized routing, both MAGs SHOULD support these encapsulation modes for the user packets 💅. They're the same ones defined for the PMIPv6 tunnel between the LMA and the MAG, so it's giving consistency ✨
- IPv4-or-IPv6-over-IPv6 [RFC5844]
- IPv4-or-IPv6-over-IPv4 [RFC5844]
- IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
- TLV-header UDP tunneling [RFC5845]
- Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
Now the big rule 🚨: MAG1 and MAG2 MUST use the same tunneling mechanism for the data traffic tunneled between them. The encapsulation mode they use SHOULD be configurable, and it is RECOMMENDED that:
- By default, the inter-MAG tunnel uses the same encapsulation mechanism as the PMIPv6 tunnel between the LMA and the MAGs 🌸. MAG1 and MAG2 automatically start using that mechanism, so you don't need any special configuration on the MAGs and they don't have to negotiate a dynamic tunneling mechanism between themselves 🦋.
- Configuration on the MAGs can override the default from Option 1 above 🍓. MAG1 and MAG2 MUST be configured with the same mechanism, and this is most likely to be uniform across the whole PMIPv6 domain 👑. If the packets on the PMIPv6 tunnel can't be uniquely mapped onto the configured inter-MAG tunnel, this scenario isn't applicable, and Option 3 below SHOULD directly be applied 🙈.
- An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default from Option 1 above ⭐. The negotiation mechanism itself is outside the scope of this document, so we're leaving it alone 🧚.
7. Scenario A12: Two MNs Attached to the Same MAG with Different LMAs 💖
Okay this one's a vibe 🌈. Both MNs are attached to the same MAG, but they're anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is anchored at LMA2. Also, the two LMAs are part of the same Provider Domain 🏰.
Internet
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+------------------+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 5So here's the tea ☕: neither LMA has any way to figure out that the two Mobile Nodes are attached to the same MAG 🫣. Only the MAG can possibly tell that the two Mobile Nodes in the communication are both attached to it. That's why localized routing MUST be initiated by the MAG 👑.
The MAG sends an LRI message to each LMA, containing the MN-ID, the HNP, and the counterpart LMA address 📨. Each LMA decides on its own whether to support local forwarding, based on the policy configured for that LMA 🧠. Each LMA MUST respond to the LRI message with an LRA message 💌. If the LR initiation worked on the LMA, the Status value in the received LRA is set to zero. Once the MAG has both LRA messages, each with Status zero (success) from the two different LMAs, the MAG will conclude that it can give local forwarding support to the two Mobile Nodes 🎉.
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG | |LMA1| |LMA2|
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data | data |
|<--------------------->|<--------->|<----------->|
| | | | |
| | data | data |
| |<--------->|<----------------------->|
| | | | |
| | | | |
| | | LRI(Opt1) | |
| | |---------->| |
| | | | |
| | | LRI(Opt2) |
| | |------------------------>|
| | | | |
| | | LRA(Opt3) | |
| | |<----------| |
| | | | |
| | | LRA(Opt4) |
| | |<------------------------|
| | | | |
| | | | |
| | | | |
| data | | |
|<--------------------->| | |
| | | | |
| | data | | |
| |<--------->| | |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP
Opt2: MN2-ID,MN2-HNP
Opt3: U=0,MN1-ID,MN1-HNP
Opt4: U=0,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
Figure 67.1. Handover Considerations 🦋
Here's what happens when things move 🏃♀️. If one of the MNs, say MN1, detaches from its current MAG (in this case MAG1) and attaches to another MAG (say nMAG1), the current MAG MUST immediately stop using the LRE and MUST send all packets originated by the other MN (MN2) towards its LMA (in this case LMA2) 💅.
8. Scenario A22: Two MNs Attached to Different MAGs with Different LMAs 💀
This scenario isn't covered in this document, since PMIPv6 doesn't define any form of inter-LMA communication 🙅♀️. When a supported scenario, like Scenario A12, morphs into Scenario A22, the node that started the localized routing session MUST tear it down, so you don't get lasting packet loss 😭. This can cause transient packet loss while routing switches from the localized path back to the normal path through the LMAs. For loss-sensitive apps, that can mean observable service disruptions 💔. In deployments where Scenario A22 is possible, using localized routing is NOT RECOMMENDED when packet-loss-sensitive applications are in use 🚫.
9. IPv4 Support in Localized Routing 🌸
PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in [RFC5844] 🌍. To set up and maintain localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the IPv4 HoAs into their LREs. The MAGs MUST also support encapsulation of IPv4 packets as described in [RFC5844]. And the localized routing protocol messages MUST include an IPv4 HoA option in their signaling messages so IPv4 addresses work for localized routing 🫶.
If the transport network between the PMIPv6 entities involved in localized routing is IPv4-only, the LRI and LRA messages MUST be encapsulated similarly to the PBU/PBA messages, as specified in [RFC5844] 🧚. The encapsulation mode used SHOULD be identical to the one used to transport PBU and PBA messages 🎀.
10. Message Formats 📜
The localized routing messages use two new Mobility Header types, 17 and 18 ✨. The LRI message requests creation or deletion of localized routing state, and the LRA message acknowledges that creation or deletion 💜.
10.1. Localized Routing Initiation (LRI) 🍓
The LRI messages use a new Mobility Header type (17) 🌈. The LMA sends an LRI message to a MAG to request local forwarding for a pair of MNs. The MAG may also send this message to ask the two LMAs to offer local forwarding, as described in Section 7 💖.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown of the fields 🔍:
Sequence Number: A monotonically increasing integer. The sending node sets it in a request message, and it's used to match a reply to that request.Reserved: This field is unused and MUST be set to zero 🙈.Lifetime: The requested time, in seconds, for which the sender wants local forwarding. A value of0xffff(all ones) means an infinite lifetime ♾️. When it's set to 0, it's a request to stop localized routing 🛑.Mobility Options: MUST contain two separate MN-ID options, followed by one or more HNPs for each of the MNs. For example, for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID, and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple MUST be present in this order: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP] 👑. The MN-ID and HNP options are the same as in [RFC5213]. The LRI MAY contain the remote MAG IPv6 address option. It's formatted identically to the HNP option, except it uses a different Type code, and the Prefix Length is always equal to 128 bits (see Section 10.1) 🦋.
The LRI message SHOULD be re-transmitted if a corresponding LRA message isn't received within LRA_WAIT_TIME time units. It gets retried up to a maximum of LRI_RETRIES, with each attempt separated by LRA_WAIT_TIME time units ⏰🔁.
10.2. Localized Routing Acknowledgment (LRA) ✨
okay so this one is the reply message 💌 the LRA messages use a brand new Mobility Header type (18) 🦋 a MAG sends an LRA to the LMA as a response to the LRI message, and an LMA can also send one back to a MAG as a response to the LRI, which is covered in Section 7. it's giving reply energy, bestie 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Sequence Number 🔢: copied from the sequence number field of the LRI message being responded to. matching the number, so the replies line up 🫶
- 'U' flag 🚩: when set to 1, the LRA is sent unsolicited (aka nobody asked, but she's showing up anyway 💀)
- Lifetime ⏳: this is a new requested value. the MAG MUST wait for the regular LRI message to confirm that the request is acceptable to the LMA. so no vibing early, the LMA has the final say 👑
- Reserved 🫧: unused, and it MUST be set zero.
- Status 🚦: an 8-bit unsigned integer that shows how processing went. values under 128 mean the LRA was processed successfully by the mobility entities (LMA or MAG) ✨ values of 128 or higher mean it got rejected 💔 these Status values are currently defined:
0: Success
128: Localized Routing Not Allowed
129: MN Not Attached- Lifetime (again, the real meaning 🧚): the time, in seconds, for which local forwarding is supported. it's typically copied from the matching field in the LRI message 🍓
- Mobility Options 🎀: when Status code is 0, it MUST contain the [MN-ID, HNP] tuples in the same order as in the LRI message. when Status code is not 0, it MUST contain only those [MN-ID, HNP] tuples for which local forwarding is supported. the MN-ID and HNP options are the same as the ones described in [RFC5213] 💜
11. New Mobility Option 🦋
11.1. MAG IPv6 Address 🌸
okay this one is the MAG IPv6 address mobility option, and it carries the IPv6 address of a MAG involved in localized routing 🫧 it has an alignment requirement of 8n+4, so keep that in mind, bestie 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAG IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 🏷️: the value is 51 🎀
- Length 📏: an 8-bit unsigned integer giving the length of the option in octets, excluding the type and length fields. this field MUST be set to 18 💅
- Reserved (R) 🫧: this 8-bit field is unused. the value MUST be initialized to 0 by the sender and MUST be ignored by the receiver 🙈
- Address Length 📐: this field MUST be set to 128 💜
- MAG IPv6 Address 🌐: a 16-byte field containing the MAG's IPv6 address ✨
12. Configuration Variables ⚙️
okay so the LMA and the MAG MUST allow the following variables to be configurable 🎀 yes, they're required to be configurable, no cap 🧁
LRA_WAIT_TIME⏱️: this variable sets the time interval, in seconds, between successive retransmissions of an LRI message. the default value is 3 seconds ✨LRI_RETRIES🔁: this variable indicates the maximum number of times the initiator retransmits an LRI message before stopping. the default value for this variable is 3 💖
13. Security Considerations 🔐
okay bestie, this part is SERIOUS so pay attention 😭🔥 the protocol inherits the threats to [RFC5213] that are identified in [RFC4832] 💀 the protocol in this document uses the same security association as defined in [RFC5213] between the LMA and the MAG to protect the LRI and LRA messages 🫶 this document also assumes that a MAG-MAG security association already exists if LR needs to be supported between them 🦋
support for integrity protection using IPsec is REQUIRED 🛡️ but support for confidentiality is OPTIONAL 🌈 and the MAGs MUST perform ingress filtering on the MN-sourced packets before encapsulating them into MAG-MAG tunnels, in order to prevent address spoofing 🚫🎀 no spoofing, periodt 👑
14. IANA Considerations 📋
the Localized Routing Initiation (described in Section 10.1) and the Localized Routing Acknowledgment (described in Section 10.2) have each been assigned a Mobility Header type (17 and 18, respectively) from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at http://www.iana.org/assignments/mobility-parameters 🧚
the MAG IPv6 Address has been assigned a Mobility Option type (51) from the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters 🍓
15. Contributors 💜
this document merges ideas from five different draft documents addressing the PMIP localized routing problem 🌈 the authors of those drafts are listed below, in alphabetical order 💅
Kuntal Chowdhury <kchowdhury@starentnetworks.com>
Ashutosh Dutta <adutta@niksun.com>
Rajeev Koodli <rkoodli@starentnetworks.com>
Suresh Krishnan <suresh.krishnan@ericsson.com>
Marco Liebsch <marco.liebsch@nw.neclab.eu>
Paulo Loureiro <loureiro@neclab.eu>
Desire Oulai <desire.oulai@videotron.com>
Behcet Sarikaya <sarikaya@ieee.org>
Qin Wu <sunseawq@huawei.com>
Hidetoshi Yokota <yokota@kddilabs.jp>
16. Acknowledgments 🫶
the authors would like to thank Sri Gundavelli, Julien Abeille, Tom Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel, and Stephen Farrell for their comments and suggestions 💖 the whole squad showed up 🙌
17. References 📚
17.1. Normative References 🔒
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC
5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.17.2. Informative References 📖
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832, April
2007.
[RFC6279] Liebsch, M., Ed., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
(PMIPv6) Localized Routing Problem Statement", RFC 6279,
June 2011.Authors' Addresses 🦋
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Rajeev Koodli
Cisco Systems
EMail: rkoodli@cisco.com
Paulo Loureiro
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
EMail: loureiro@neclab.eu
Qin Wu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 21001
China
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Ashutosh Dutta
NIKSUN
EMail: adutta@niksun.com📦 where this page comes from
- ietf: rfc6705 2012-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms