RFC 8127
Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor
RFC 8127: Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor ✨
Title block tea 🫖 Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's RFC 8127 📜. It's on the Standards Track (so it's an official spec, not just a vibe), it was published in August 2017, and its ISSN is 2070-1721. The header doesn't list any documents it obsoletes or updates, so it's standing on its own 💅.
The authors are D. Patki, S. Gundavelli (both from Cisco), J. Lee (Sangmyung University), Q. Fu (China Mobile), and L. Bertz (Sprint). Five people and a whole mobility vibe 🦋.
Abstract
Okay so the big idea 💜: this spec adds a brand new extension called LMA-Controlled-MAG-Session-Params to Proxy Mobile IPv6. The local mobility anchor (LMA) in a Proxy Mobile IPv6 domain can use it to tell a mobile access gateway (MAG) to enforce specific values for things like heartbeat and binding refresh parameters. It's the LMA being the boss, honestly 👑.
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, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶. If you want more on Internet Standards, check Section 2 of RFC 7841 🌸.
For the current status, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc8127 🔗.
Copyright Notice
Copyright (c) 2017 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 publication date. Please actually read these, 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 with no warranty, as the Simplified BSD License describes 💀.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 4
3.1. Format of the LCMP Sub-Options . . . . . . . . . . . . . 5
3.1.1. Binding Re-registration Control Sub-Option . . . . . 6
3.1.2. Heartbeat Control Sub-Option . . . . . . . . . . . . 7
4. Protocol Configuration Variables . . . . . . . . . . . . . . 8
4.1. Local Mobility Anchor -- Configuration Variables . . . . 8
5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Local Mobility Anchor Considerations . . . . . . . . . . 10
5.2. Mobile Access Gateway Considerations . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141. Introduction 🌈
Okay so picture a big Proxy Mobile IPv6 (PMIPv6) [RFC5213] setup, like a residential deployment, with tens of thousands of mobile access gateways (MAGs) spread all over the place 😭. Managing that many MAGs is already a lot, and if nobody's centrally managing them, keeping their configs consistent is genuinely so hard 💀.
Here's the drama 🎭: setting aggressive values for things like the re-registration timeout and the heartbeat interval can absolutely flood the local mobility anchor (LMA) with signaling load 🚨.
So this document gives the LMA a new option to control the MAG parameters, like the re-registration frequency [RFC5213] and the heartbeat frequency [RFC5847] 🦋. When the LMA enforces these tunable parameters centrally, Service Providers get way better control over how the MAGs behave, plus a deterministic signaling load on the LMA. Iconic, honestly 👑.
2. Conventions and Terminology ✨
2.1. Conventions 💅
Here's the BCP 14 squad 🔥: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". These words are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🙈.
2.2. Terminology 📚
All the terms in this document are interpreted as defined in [RFC5213], [RFC5847], and [RFC7563]. Read those first, bestie 🧚.
3. Protocol Extension 🎀
So the LMA-Controlled MAG Parameters (LCMPs) option is a mobility header option that exchanges info about the parameters an LMA enforces on a MAG 💜. It can only be included in the Proxy Binding Acknowledge (PBA) message, and there is a rule here: there MUST NOT be more than a single instance of this mobility option in a given PBA message 🙅♀️. The option MUST contain one or more LCMP sub-options, and each sub-option carries one specific configuration parameter. The sub-options are defined in Section 3.1. The LCMP option has an alignment requirement of 4n+2 [RFC8200] ✨.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCMP Sub-Option(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: LMA-Controlled MAG Parameters Option
Type 🍓: this MUST be set to the value of 62, which marks it as an LMA-Controlled-MAG-Parameters option.
Length 🌸: an 8-bit unsigned integer giving the length in octets of the option, not counting the Type and Length fields.
LCMP Sub-Option(s) 🦋: the sub-options are described in the sections below. They can show up in any order. Including any specific sub-option is optional, but at least one sub-option MUST be present 💖.
3.1. Format of the LCMP Sub-Options 🌈
The LCMP sub-options carry info about the various parameters that need to be configured on the MAG. They can be included in the LCMP option defined in Section 3, and they have an alignment requirement of 4n. Here's what the format looks like 💅.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCMP Type | LCMP Length | Sub-Option Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: LMA-Controlled MAG Parameters Sub-Option
Type 🧚: an 8-bit unsigned integer for the type of the LCMP sub-option. This spec defines these types:
0 - Reserved1 - Binding Re-registration Control Sub-Option2 - Heartbeat Control Sub-Option
Length 🔥: an 8-bit unsigned integer for the number of octets needed to encode the Option Data, again not counting the LCMP Type and LCMP Length fields of the sub-option.
3.1.1. Binding Re-registration Control Sub-Option 💜
This sub-option is a mobility sub-option carried in the LCMP mobility option from Section 3. It carries timer values related to re-registration, and there MUST be no more than a single instance of it in the LCMP option. Here's the layout 🎀.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCMP Type = 1 | LCMP Length | Re-registration-Start-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial-Retransmission-Time | Maximum-Retransmission-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Binding Re-registration Control Sub-Option
LCMP Type 🦋: 1, for the Binding Re-registration Control Sub-Option.
LCMP Length 🌷: 6.
Re-registration-Start-Time ⏰: a 16-bit unsigned integer for the number of time units before the PMIPv6 binding lifetime expires when the registration refresh process needs to kick in. One time unit is 4 seconds 🫶.
Initial-Retransmission-Time ⏳: a 16-bit unsigned integer for the minimum delay in seconds before the first Proxy Binding Update (PBU) retransmission of the exponential backoff process 🔁.
Maximum-Retransmission-Time 🛑: a 16-bit unsigned integer for the maximum delay in seconds before the last PBU retransmission message of the exponential backoff process 💀.
3.1.2. Heartbeat Control Sub-Option 💖
Here's the heartbeat one 🫀.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCMP Type = 2 | LCMP Length | HB-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HB-Retransmission-Delay | HB-Max-Retransmissions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Heartbeat Control Sub-Option
LCMP Type 🌸: 2, for the Heartbeat Control Sub-Option.
LCMP Length 🍓: 6.
HB-Interval 💜: a 16-bit unsigned integer for the heartbeat interval. This is the time delay in seconds after a successful heartbeat exchange (heartbeat request followed by response) before the next heartbeat exchange can be triggered 🔔.
HB-Retransmission-Delay ⏱️: a 16-bit unsigned integer for the minimum time delay in seconds before a heartbeat message is retransmitted 🌀.
HB-Max-Retransmissions 🧮: a 16-bit unsigned integer for the maximum number of heartbeat retransmissions 🎯.
4. Protocol Configuration Variables 🌈
4.1. Local Mobility Anchor -- Configuration Variables ⚙️
okay bestie, the system management is the one setting these up 🎀 and the rule is that the configured values MUST survive server reboots and service restarts 😭 they are not allowed to vanish just because the box blinked.
EnableLCMPSubOptReregControl 🦋 is a flag that shows whether support for the Binding Re-registration Control Sub-Option is on. Its default is (0), so support is disabled out of the box 💤
EnableLCMPSubOptHeartbeatControl 💜 is the same kind of flag, but for the Heartbeat Control Sub-Option. Default is (0), so disabled too ✨
Next up, these variables MAY be defined at different granularities, like per binding, per cluster of bindings, per peering MAG, per cluster of peering MAGs, or any other custom grouping 🧚 no matter how you slice the config, the LMA MUST be able to figure out the value of these variables for every single binding. non-negotiable 💅
LCMPReregistrationStartTime 🌸 sets the minimum number of seconds before the PMIPv6 binding lifetime expires when the registration refresh process SHOULD kick in. The default is 10 units, and each unit is 4 seconds.
LCMPInitialRetransmissionTime ⏱️ sets the minimum delay in seconds before the first PBU retransmission in the exponential backoff process. This is the same thing as INITIAL_BINDACK_TIMEOUT from Section 6.9.4 of [RFC5213]. Default is 1 second.
LCMPMaximumRetransmissionTime 🌙 sets the maximum delay in seconds before the last PBU retransmission in that same backoff process. This matches MAX_BINDACK_TIMEOUT from Section 6.9.4 of [RFC5213]. Default is 32 seconds.
LCMPHeartbeatInterval 💖 is the delay in seconds after a successful heartbeat exchange (a heartbeat request followed by a response) before the next exchange can be triggered. Default is 60 seconds. This delay SHOULD NOT be less than 30 seconds or more than 3600 seconds. The value MAY be derived from HEARTBEAT_INTERVAL in Section 5 of [RFC5847] if it's configured on the LMA 🔥
LCMPHeartbeatRetransmissionDelay 🍓 is the minimum delay in seconds before a heartbeat message gets retransmitted. The value SHOULD be less than LCMPHeartbeatInterval. Default is 5 seconds.
LCMPHeartbeatMaxRetransmissions 👑 is the maximum number of heartbeat retransmissions. Default is 3. The value MAY be derived from MISSING_HEARTBEATS_ALLOWED in Section 5 of [RFC5847] if it's configured on the LMA.
5. Protocol Considerations ✨
The following considerations apply to the LMA and the MAG 🫶
To support this extension, the conceptual Binding Cache Entry data structure that the LMA keeps (described in Section 5.1 of [RFC5213]) and the conceptual Binding Update List entry data structure that the MAG keeps (described in Section 6.1 of [RFC5213]) need to be extended. They need to store the LCMP option information elements defined below 🧠
LCMPReregistrationStartTimeLCMPInitialRetransmissionTimeLCMPMaximumRetransmissionTimeLCMPHeartbeatIntervalLCMPHeartbeatRetransmissionDelayLCMPHeartbeatMaxRetransmissions
5.1. Local Mobility Anchor Considerations 🏠
This is the LMA's checklist, bestie 📋 When a PBU message [RFC5213] arrives from a MAG, the LMA MUST check whether EnableLCMPSubOptReregControl is configured and set to (1). If it is, and LCMPReregistrationStartTime, LCMPInitialRetransmissionTime, and LCMPMaximumRetransmissionTime are all set to NON_ZERO values, then the LMA MUST include the Binding Re-registration Control Sub-Option in the LCMP mobility option. That option then rides along inside the PBA message. But if EnableLCMPSubOptReregControl is set to (1) and any of those three variables is set to a ZERO value, the LMA MUST report a configuration error and reject the binding request by sending a PBA message with status code '128 - Reason Unspecified' [RFC5213] 🚫
The LMA MUST also check whether EnableLCMPSubOptHeartbeatControl is configured and set to (1). If it is, and LCMPHeartbeatInterval, LCMPHeartbeatRetransmissionDelay, and LCMPHeartbeatMaxRetransmissions are all set to NON_ZERO values, then the LMA MUST include the Heartbeat Control Sub-Option in the LCMP mobility option, which goes inside the PBA message. If EnableLCMPSubOptHeartbeatControl is set to (1) and any of those three is set to a ZERO value, the LMA MUST report a configuration error and reject the binding request by sending a PBA message with status code '128 - Reason Unspecified' [RFC5213] 💀
5.2. Mobile Access Gateway Considerations 🛰️
Now the MAG's side 🥰 If the PBA message [RFC5213] from the LMA has the LCMP mobility option and the Binding Re-registration Control Sub-Option, then the MAG MUST overwrite its locally configured binding re-registration timer parameters with the ones from that sub-option. And if any parameter in the Binding Re-registration Control Sub-Option is ZERO, the PBA message MUST be ignored and an error message SHOULD be logged 🙈
Same energy for heartbeats: if the LCMP mobility option contains the Heartbeat Control Sub-Option, the MAG MUST overwrite its local heartbeat-related timer parameters with the ones received. If any parameter in the Heartbeat Control Sub-Option is ZERO, except HB-Retransmission-Delay, then the PBA message MUST be ignored and an error message SHOULD be logged 📝
6. IANA Considerations 🧾
IANA has updated the "Mobile IPv6 parameters" registry as described here 🌈
- Action 1: This specification defines a new mobility header option, "LMA-Controlled MAG Parameters". It's described in Section 3. The type value 62 has been assigned for this option in the "Mobility Options" registry, which is defined in [RFC6275].
- Action 2: This specification defines a new mobility sub-option format, the LCMP sub-option. Its format is described in Section 3.1, and it can be carried in the LCMP option. The type values for this sub-option are managed by IANA under the "LMA-Controlled MAG Parameters Sub-Option Type Values" registry. Per this document, IANA has reserved the following type values. New LCMP sub-option type values are approved through Expert Review [RFC8126].
+---+-----------------------------------------------------+
| 0 | Reserved |
+---+-----------------------------------------------------+
| 1 | Binding Re-registration Control Sub-Option |
+---+-----------------------------------------------------+
| 2 | Heartbeat Control Sub-Option |
+---+-----------------------------------------------------+7. Security Considerations 🔐
The LCMP option defined in this specification lets you configure re-registration and heartbeat frequencies. This option is defined to be carried in Proxy Binding Update and Proxy Binding Acknowledgement messages. It gets carried like any other mobility header option, as specified, and it does not require any special security considerations 🛡️ (I know, I know, the drama is real, but this part is chill).
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC5847] Devarapalli, V., Ed., Koodli, R., Ed., Lim, H., Kant, N.,
Krishnan, S., and J. Laganier, "Heartbeat Mechanism for
Proxy Mobile IPv6", RFC 5847, DOI 10.17487/RFC5847, June
2010, <https://www.rfc-editor.org/info/rfc5847>.
[RFC7563] Pazhyannur, R., Speicher, S., Gundavelli, S., Korhonen,
J., and J. Kaippallimalil, "Extensions to the Proxy Mobile
IPv6 (PMIPv6) Access Network Identifier Option", RFC 7563,
DOI 10.17487/RFC7563, June 2015,
<https://www.rfc-editor.org/info/rfc7563>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.Acknowledgements 🫶
The authors would like to thank the DMM Working Group for all the comments and discussions on this document. The authors would also like to thank Suresh Krishnan, Ralph Droms, Mirja Kuhlewind, Alexey Melnikov, and Ben Campbell for their review feedback 🥹
The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga KOREA Project' grant from the Ministry of Science, ICT and Future Planning, Korea 🇰🇷✨
Authors' Addresses 💌
Dhananjay Patki
Cisco
Cessna Business Park SEZ, Kadubeesanahalli
Bangalore, Karnataka 560087
India
Email: dhpatki@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sgundave@cisco.com
Jong-Hyouk Lee
Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu
Cheonan 31066
Republic of Korea
Email: jonghyouk@smu.ac.kr
Qiao Fu
China Mobile
Xuanwumenxi Ave. No.32
Beijing
China
Email: fuqiao1@outlook.com
Lyle T. Bertz
Sprint
Kansas
United States of America
Email: Lyle.T.Bertz@sprint.com📦 where this page comes from
- ietf: rfc8127 2017-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms