diff options
Diffstat (limited to 'doc/rfc/rfc5845.txt')
| -rw-r--r-- | doc/rfc/rfc5845.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc5845.txt b/doc/rfc/rfc5845.txt new file mode 100644 index 0000000..0e76ba9 --- /dev/null +++ b/doc/rfc/rfc5845.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Muhanna +Request for Comments: 5845 M. Khalil +Category: Standards Track Ericsson +ISSN: 2070-1721 S. Gundavelli + K. Leung + Cisco + June 2010 + + + Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 + +Abstract + + This specification defines a new mobility option for allowing the + mobile access gateway and the local mobility anchor to negotiate + Generic Routing Encapsulation (GRE) encapsulation mode and exchange + the downlink and uplink GRE keys that are used for marking the + downlink and uplink traffic that belong to a specific mobility + session. In addition, the same mobility option can be used to + negotiate the GRE encapsulation mode without exchanging the GRE keys. + +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. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5845. + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + + +Muhanna, et al. Standards Track [Page 1] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 + 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4 + 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 + 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6 + 3.3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . 6 + 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 + 3.3.2. GRE Key Exchange during Binding Re-Registration . . . 7 + 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8 + 4.1. Extensions to the Conceptual Data Structure . . . . . . . 8 + 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 + 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10 + 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10 + 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11 + 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12 + 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13 + 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14 + 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. Data Packets Processing Considerations . . . . . . . . . . . . 15 + 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15 + 7.2. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16 + 7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18 + 7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 18 + 7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 19 + 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 20 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 2] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + +1. Introduction + + The Proxy Mobile IPv6 specification [RFC5213] and IPv4 Support for + Proxy Mobile IPv6 [RFC5844] allow the use of IPv6 and IPv4 + encapsulation modes as specified in [RFC2473] and [RFC2003] for the + tunneled traffic between the local mobility anchor (LMA) and the + mobile access gateway (MAG). There are scenarios where these + encapsulation modes are not sufficient to uniquely identify the + destination of packets of a specific mobility session. Thus, there + is a need for an encapsulation mode with richer semantics. The + Generic Routing Encapsulation (GRE) [RFC2784], and the Key extension + as defined in [RFC2890], has the required semantics to allow such a + distinction for use in Proxy Mobile IPv6. + + This specification defines the GRE Key option to be used for the + negotiation of GRE encapsulation mode and exchange of the uplink and + downlink GRE keys. The negotiated downlink and uplink GRE keys can + be used for marking the downlink and uplink traffic for a specific + mobility session. In addition, this specification enables the mobile + access gateway and the local mobility anchor to negotiate the use of + GRE encapsulation mode without exchanging the GRE keys. + + This specification has no impact on IPv4 or IPv6 mobile nodes. + +2. Conventions and Terminology + +2.1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + specification are to be interpreted as described in RFC 2119 + [RFC2119]. + +2.2. Terminology + + All the general mobility-related terminology and abbreviations are to + be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile + IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844] + specifications. The following terms are used in this specification. + + Downlink Traffic + + The traffic in the tunnel between the local mobility anchor and + the mobile access gateway, heading towards the mobile access + gateway and tunneled at the local mobility anchor. This traffic + is also called forward direction traffic. + + + + + +Muhanna, et al. Standards Track [Page 3] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + Uplink Traffic + + The traffic in the tunnel between the mobile access gateway and + the local mobility anchor, heading towards the local mobility + anchor and tunneled at the mobile access gateway. This traffic is + also called reverse direction traffic. + + Downlink GRE Key + + The GRE key is assigned by the mobile access gateway and used by + the local mobility anchor to mark the downlink traffic that + belongs to a specific mobility session as described in this + specification. + + Uplink GRE Key + + The GRE key is assigned by the local mobility anchor and used by + the mobile access gateway to mark the uplink traffic that belongs + to a specific mobility session as described in this specification. + + + A Policy Check + + When a local mobility anchor receives an initial, handoff- + triggered Binding Lifetime Extension, or Binding Lifetime + Extension Proxy Binding Update for a mobility session, the local + mobility anchor determines if the GRE encapsulation mode only or + GRE encapsulation and GRE keys are required based on a policy + check. This policy could be a per-MAG-LMA pair, a per-LMA local + policy, a per-MN policy, or the combination of any of them. + +3. GRE Encapsulation and Key Exchange + + This section describes how GRE encapsulation mode is negotiated and + the GRE keys are dynamically exchanged using Proxy Mobile IPv6 + protocol [RFC5213] signaling. + +3.1. GRE Encapsulation Overview + + Using the GRE Key option defined in this specification, the mobile + access gateway and the local mobility anchor can negotiate GRE + encapsulation mode only or GRE encapsulation mode and exchange the + GRE keys for marking the downlink and uplink traffic. In the case + when GRE encapsulation mode only is negotiated between the mobile + access gateway and the local mobility anchor, then no GRE keys are + used. + + + + + +Muhanna, et al. Standards Track [Page 4] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + However, once the GRE keys have been exchanged between the mobile + access gateway and the local mobility anchor as per this + specification, the mobile access gateway will use the uplink GRE key + that is assigned by the local mobility anchor in the GRE header of + the uplink payload packet. Similarly, the local mobility anchor will + use the downlink GRE key as negotiated with the mobile access gateway + in the GRE header of the downlink payload packet. + + The following illustration explains the use of GRE encapsulation mode + and the GRE keys for supporting the usecase where overlapping IPv4 + private address [RFC1918] allocation is in use. + + +------------+ + | Operator-A | + | | + | 10.x.0.0/16| + +------------+ + / + +------+ +------+ / + | | ========================== | | / + MN-1---| | / \ | | / Key-1 + | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic + MN-2---| A |--| |--| M |- + | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 + MN-3---| | \ / | | \Traffic + | | ========================== | | \ + MN-4---| | Proxy Mobile IPv6 Tunnel | | \ + +------+ +------+ \ + \ + Operator-C: Access Network +------------+ + | Operator-B | + | | + | 10.x.0.0/16| + +------------+ + + Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping + + Figure 1 illustrates a local mobility anchor providing mobility + service to mobile nodes that are from different operators and are + assigned IPv4 addresses from overlapping private address space. In + this scenario, the mobile access gateway and the local mobility + anchor must be able to distinguish flows belonging to different + operators. + + The mobile nodes MN-1 and MN-2 are visiting from Operator-A, and the + mobile nodes MN-3 and MN-4 are visiting from Operator-B. The mobile + access gateway and the local mobility anchor exchange a specific pair + + + + +Muhanna, et al. Standards Track [Page 5] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + of downlink and uplink GRE keys and save them as part of the mobile + node's binding to be used for identifying the flows belonging to each + mobile node. + + The LMA and the MAG will be able to distinguish each mobile node + flow(s) based on the GRE key present in the GRE header of the + tunneled payload packet, and route them accordingly. However, the + GRE keys, as in this specification, apply to the individual mobility + binding updated by the Proxy Binding Update but not to all bindings + that the mobile may have registered following procedures described in + [RFC5648]. + +3.2. GRE Encapsulation Mode Only + + In order for the mobile access gateway to request GRE encapsulation + mode only without exchanging the GRE keys, the mobile access gateway + MUST include the GRE Key option but omit the GRE Key Identifier field + in the Proxy Binding Update. + + If the local mobility anchor supports GRE encapsulation and the + received Proxy Binding Update contains the GRE Key option but the GRE + Key Identifier field is omitted, the mobile access gateway is + requesting GRE encapsulation without exchanging the GRE keys + dynamically. If the Proxy Binding Update processing is successful, + the local mobility anchor sends a successful Proxy Binding + Acknowledgement message with the GRE Key option but the GRE Key + Identifier field is omitted. + + When the mobile access gateway and the local mobility anchor + successfully negotiate the GRE encapsulation mode only, then no GRE + keys are used. + +3.3. GRE Encapsulation and Key Exchange + + The following subsections describe how the mobile access gateway and + the local mobility anchor negotiate GRE encapsulation and exchange + downlink and uplink GRE keys using the Proxy Mobile IPv6 registration + procedure. + +3.3.1. Initial GRE Key Exchange + + When the mobile access gateway determines, based on, e.g., private + IPv4 address support [RFC1918], the mobile access gateway local + policy, or the MAG-LMA peer agreement, that GRE encapsulation is + needed and GRE keys are required, the mobile access gateway MUST + include the GRE Key option in the initial Proxy Binding Update + + + + + +Muhanna, et al. Standards Track [Page 6] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + message sent to the local mobility anchor. The mobile access gateway + MUST include the downlink GRE key in the GRE Key Identifier field of + the GRE Key option. + + After the local mobility anchor successfully processes the initial + Proxy Binding Update and accepts the GRE encapsulation request and + the downlink GRE key based on a policy check, the local mobility + anchor MUST include the GRE Key option with the uplink GRE key in the + GRE Key Identifier field in a successful Proxy Binding + Acknowledgement and send it to the mobile access gateway. + +3.3.2. GRE Key Exchange during Binding Re-Registration + + If the local mobility anchor has successfully negotiated and + exchanged the initial GRE keys with the mobile access gateway for a + specific mobile node's mobility session, the local mobility anchor + MUST maintain the same negotiated uplink GRE key for the lifetime of + that mobility session. However, for administrative reasons, e.g., + local mobility anchor reboot, the local mobility anchor MAY change + the uplink GRE key for the mobility session. In that case, some + packet loss may be experienced. + + If the mobile access gateway has successfully negotiated and + exchanged the initial GRE keys with the local mobility anchor for a + specific mobile node's mobility session, the mobile access gateway + MUST include the GRE Key option with the downlink GRE key in the + Proxy Binding Update that is used to request a Binding Lifetime + Extension. In this case, if the local mobility anchor successfully + processes the Proxy Binding Update message, the local mobility anchor + MUST return the same uplink GRE key that was exchanged with the + mobile access gateway in the last successful Proxy Binding Update for + the same mobility session in the GRE Key option in a successful Proxy + Binding Acknowledgement message. + + However, during inter-MAG handoff and if the new mobile access + gateway determines, based on, e.g., private IPv4 address support, the + mobile access gateway local policy, the MAG-LMA peer agreement, or an + indication during the handoff process, that GRE encapsulation and GRE + keys exchange are required, the new mobile access gateway MUST + include the GRE Key option with the downlink GRE key in the Proxy + Binding Update that is used to request an after-handoff Binding + Lifetime Extension. In this case, the new mobile access gateway may + either pick a new downlink GRE key or use the downlink GRE key that + was used by the previous mobile access gateway for the same binding. + For the new mobile access gateway to know the downlink GRE key used + by the previous mobile access gateway, it may require transfer of + + + + + +Muhanna, et al. Standards Track [Page 7] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + context from the previous mobile access gateway to the new mobile + access gateway during a handoff. Such mechanisms are out of scope + for this specification. + + If the local mobility anchor successfully processes a handoff- + triggered Binding Lifetime Extension Proxy Binding Update message + that contains a GRE Key option with a downlink GRE key included, the + local mobility anchor MUST return the same uplink GRE key that was + exchanged with the previous mobile access gateway for the same + mobility session in the GRE Key option in a successful Proxy Binding + Acknowledgement. + + If the local mobility anchor receives a handoff-triggered Binding + Lifetime Extension Proxy Binding Update message without the GRE Key + option for a Binding Cache entry (BCE) that is using GRE keys and GRE + encapsulation, the local mobility anchor makes a policy check + regarding GRE encapsulation and GRE key exchange. If, according to + the policy check, GRE encapsulation and GRE key exchange are + required, the local mobility anchor MUST reject the Proxy Binding + Update by sending a Proxy Binding Acknowledgement message with the + Status field set to GRE_KEY_OPTION_REQUIRED as defined in + Section 6.4. Otherwise, the local mobility anchor SHOULD accept the + Proxy Binding Update, and if it is processed successfully, the local + mobility anchor MUST return a successful Proxy Binding + Acknowledgement without including the GRE Key option. + +4. Mobile Access Gateway Considerations + +4.1. Extensions to the Conceptual Data Structure + + Every mobile access gateway maintains a Binding Update List (BUL) + entry for each currently attached mobile node, as explained in + Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To + support this specification, the conceptual Binding Update List entry + data structure must be extended with the following four new + additional fields. + + o A flag (GRE-encapsulation-enabled) is used for indicating whether + GRE encapsulation is enabled for the mobile node's traffic. + + o The downlink GRE key used in the GRE encapsulation header of the + tunneled payload packet from the local mobility anchor to the + mobile access gateway that is destined to the mobile node. This + GRE key is generated by the mobile access gateway and communicated + to the local mobility anchor in the GRE Key option in the Proxy + Binding Update message. + + + + + +Muhanna, et al. Standards Track [Page 8] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + o The uplink GRE key used in the GRE encapsulation header of the + tunneled payload packet from the mobile access gateway to the + local mobility anchor that is originating from the mobile node. + This GRE key is obtained from the GRE Key Identifier field of the + GRE Key option present in the received Proxy Binding + Acknowledgement message sent by the local mobility anchor as + specified in this document. + + o A flag indicating whether UDP-based TLV-header format + (Section 7.2) is enabled for the mobile node's traffic. This flag + is TRUE only when UDP tunneling as in [RFC5844] and GRE + encapsulation as in this specification are both enabled for this + mobility session. + +4.2. Operational Summary + + o If the mobile access gateway determines that GRE encapsulation + mode only is required, the mobile access gateway MUST include the + GRE Key option but omit the GRE Key Identifier field in the Proxy + Binding Update message that is sent to the local mobility anchor. + + o If the mobile access gateway determines that GRE encapsulation and + GRE keys are required, the mobile access gateway MUST include the + GRE Key option with the downlink GRE key in the GRE Key Identifier + field in the Proxy Binding Update message that is sent to the + local mobility anchor. + + o After receiving a successful Proxy Binding Acknowledgement message + with the GRE Key option with the GRE Key Identifier field omitted, + the mobile access gateway MUST update the mobile node's Binding + Update List entry described in Section 4.1 by only setting the + GRE-encapsulation-enabled flag. + + o After receiving a successful Proxy Binding Acknowledgement message + with the GRE Key option and the uplink GRE key included in the GRE + Key Identifier field, the mobile access gateway MUST update the + related fields in the mobile node's Binding Update List entry + described in Section 4.1. Additionally, the mobile access gateway + MUST use the assigned uplink GRE Key for tunneling all the traffic + that belongs to this mobile node BUL entry and that originated + from the mobile node before forwarding the tunneled traffic to the + local mobility anchor. + + o If the mobile access gateway includes the GRE Key option in the + Proxy Binding Update for a specific mobile node and the local + mobility anchor accepts the Proxy Binding Update by sending a + Proxy Binding Acknowledgement with a success status code (less + than 128) other than GRE_KEY_OPTION_NOT_REQUIRED, but without the + + + +Muhanna, et al. Standards Track [Page 9] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + GRE Key option, then the mobile access gateway MUST consider that + the local mobility anchor does not support the GRE Key option as + per this specification. The mobile access gateway SHOULD NOT + include the GRE Key option in any subsequent Proxy Binding Update + message that is sent to that local mobility anchor. + + o If the mobile access gateway sent a Proxy Binding Update message + without the GRE Key option, but the received Proxy Binding + Acknowledgement has the status code GRE_KEY_OPTION_REQUIRED, + indicating that GRE encapsulation and GRE keys are required, the + mobile access gateway SHOULD resend the Proxy Binding Update + message with the GRE Key option. If the mobile access gateway + does not support the GRE Key option, it MAY log the event and + possibly raise an alarm to indicate a possible misconfiguration. + + o If the mobile access gateway sent a Proxy Binding Update message + with the GRE Key option and the downlink GRE key included and + received a successful Proxy Binding Acknowledgement message with + the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access + gateway MUST consider that GRE encapsulation and GRE keys are not + required for this specific mobility session. The mobile access + gateway follows procedures in the Proxy Mobile IPv6 specification + [RFC5213] for the handling of uplink and downlink traffic and MUST + NOT include the GRE Key option in any subsequent Proxy Binding + Update message that is sent to the local mobility anchor for this + mobility session. + + o If the mobile access gateway has successfully negotiated GRE + encapsulation and exchanged the GRE keys with the local mobility + anchor for a specific mobility session, the mobile access gateway + SHOULD NOT include the GRE Key option in the de-registration Proxy + Binding Update. + + o On receiving a packet from the tunnel with the GRE header, the + mobile access gateway MUST use the GRE key present in the GRE + extension header as an additional identifier to determine to which + mobility session this packet belongs. The GRE header is removed + before further processing takes place. + +5. Local Mobility Anchor Considerations + +5.1. Extensions to the Binding Cache Entry + + When the local mobility anchor and the mobile access gateway + successfully negotiate GRE encapsulation and exchange downlink and + uplink GRE keys, the local mobility anchor MUST maintain the downlink + and uplink GRE keys as part of the mobile node's BCE. This requires + the BCE described in Section 5.1 of the Proxy Mobile IPv6 + + + +Muhanna, et al. Standards Track [Page 10] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + specification [RFC5213] to be extended. To support this + specification, the BCE must be extended with the following four + additional fields. + + o A flag indicating whether GRE encapsulation is enabled for the + mobile node's traffic flows. + + o The downlink GRE key, assigned by the mobile access gateway and + used in the GRE encapsulation header of the tunneled payload + packet from the local mobility anchor to the mobile access + gateway. + + o The uplink GRE key, assigned by the local mobility anchor and used + in the GRE encapsulation header of the tunneled payload packet + from the mobile access gateway to the local mobility anchor. + + o A flag indicating whether UDP-based TLV-header format + (Section 7.2) is enabled for the mobile node's traffic. This flag + is TRUE only when UDP tunneling as in [RFC5844] and GRE + encapsulation as in this specification are both enabled for this + mobility session. + +5.2. Operational Summary + + o If the local mobility anchor successfully processes a Proxy + Binding Update message with the GRE Key option, but the GRE Key + Identifier field is omitted for initial GRE key exchange, the + local mobility anchor MUST include the GRE Key option but omit the + GRE Key Identifier field when responding with a successful Proxy + Binding Acknowledgement message. + + o If the local mobility anchor successfully processes a Proxy + Binding Update message with the GRE Key option and the downlink + GRE key included in the GRE Key Identifier field for initial GRE + key exchange as in Section 3.3.1, the local mobility anchor MUST + include the GRE Key option with the uplink GRE key included in the + GRE Key Identifier field when responding with a successful Proxy + Binding Acknowledgement message. + + o If the GRE tunneling is negotiated and the downlink and uplink GRE + keys have been exchanged between the mobile access gateway and the + local mobility anchor for a specific mobility session, the local + mobility anchor MUST use the negotiated downlink GRE key in the + GRE header of every packet that is destined to the mobile node of + this specific mobility session over the GRE tunnel to the mobile + access gateway. + + + + + +Muhanna, et al. Standards Track [Page 11] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + o If the received Proxy Binding Update message does not contain the + GRE Key option, and if the local mobility anchor based on a policy + check determines that GRE encapsulation and GRE keys are required, + e.g., overlapping IPv4 private addressing is in use, a local + mobility anchor local policy, or LMA-MAG peer agreement, the local + mobility anchor MUST reject the request and send a Proxy Binding + Acknowledgement message to the mobile access gateway with the + status code GRE_KEY_OPTION_REQUIRED as defined in Section 6.4. + This indicates that GRE encapsulation and GRE keys are required. + + o If, after receiving and successfully processing a Proxy Binding + Update message with the GRE Key option, the local mobility anchor + determines, based on a policy check, that GRE encapsulation and + GRE keys are not required for this specific binding, e.g., private + IPv4 addressing is not in use, the local mobility anchor SHOULD + send a successful Proxy Binding Acknowledgement message to the + mobile access gateway with the status code + GRE_KEY_OPTION_NOT_REQUIRED. In this case, the local mobility + anchor MUST NOT include the GRE Key option in the Proxy Binding + Acknowledgement. + + o If the local mobility anchor successfully processes a de- + registration Proxy Binding Update message, the local mobility + anchor follows the same de-registration process as described in + the Proxy Mobile IPv6 specification [RFC5213] to clean the Binding + Cache entry and all associated resources including the downlink + and uplink GRE keys. + + o On receiving a packet from the tunnel with the GRE header, the + local mobility anchor MUST use the GRE key in the GRE extension + header as an additional identifier to determine to which mobility + session this packet belongs. The GRE header is removed before + further processing takes place. + +6. Message Formats + + This section defines an extension to the Mobile IPv6 protocol + [RFC3775] messages. The use of the GRE Key option for supporting GRE + tunneling and GRE key exchange for Proxy Mobile IPv6 is defined in + this specification. + +6.1. GRE Key Option + + A new mobility option, the GRE Key option, is defined for use in the + Proxy Binding Update and Proxy Binding Acknowledgement messages + exchanged between the mobile access gateway and the local mobility + anchor. This option can be used for negotiating GRE encapsulation + mode only or GRE encapsulation and exchanging the downlink and uplink + + + +Muhanna, et al. Standards Track [Page 12] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + GRE keys. These GRE keys can be used by the peers in all GRE + encapsulated payload packets for marking that specific mobile node's + data traffic. + + The alignment requirement for this option is 4n. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GRE Key Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: GRE Key Option + + Type + + 33 + + Length + + An 8-bit unsigned integer indicating the length in octets of the + option, excluding the Type and Length fields. If the Length field + is set to 2, it indicates that the GRE Key Identifier field is not + being carried in the option. If the Length field is set to a + value of 6, it means that either the downlink or the uplink GRE + key is carried. + + Reserved + + These fields are unused. They MUST be initialized to zero by the + sender and MUST be ignored by the receiver. + + GRE Key Identifier + + A 32-bit field containing the downlink or the uplink GRE key. + This field is present in the GRE Key option only if the GRE keys + are being exchanged using the Proxy Binding Update and Proxy + Binding Acknowledgement messages. + +6.2. Proxy Binding Update Message Extension + + This specification extends the Proxy Binding Update message as + defined in [RFC5213] with the new TLV-header format (T) flag. The + new (T) flag is described below and shown as part of the Proxy + Binding Update message as in Figure 3. + + + + +Muhanna, et al. Standards Track [Page 13] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + 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 # | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|H|L|K|M|R|P|F|T| Reserved | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Proxy Binding Update Message + + TLV-header format (T) + + When set, this flag indicates that the mobile access gateway + requests the use of the TLV header for encapsulating IPv6 or IPv4 + packets in IPv4. The TLV-header format is described in + Section 7.2. None of the other fields or flags in the Proxy + Binding Update are modified by this specification. + +6.3. Proxy Binding Acknowledgement Message Extension + + This specification extends the Proxy Binding Acknowledgement message + as defined in [RFC5213] with the new TLV-header format (T) flag. The + new (T) flag is described below and shown as part of the Proxy + Binding Acknowledgement message as in Figure 4. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status |K|R|P|T| Res | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Proxy Binding Acknowledgement Message + + TLV-header format (T) + + When set, this flag indicates that the sender of the Proxy Binding + Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 + using TLV-header format. None of the other fields or flags in the + Proxy Binding Acknowledgement are modified by this specification. + +6.4. Status Codes + + The following status code values are defined for use in the Binding + Acknowledgement message when using Proxy Mobile IPv6. + + + + + +Muhanna, et al. Standards Track [Page 14] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + GRE_KEY_OPTION_NOT_REQUIRED (2) + + When the local mobility anchor receives a Proxy Binding Update + with the GRE Key option, and based on a policy check it determines + that GRE encapsulation is not required for this specific mobility + session, it uses this code to indicate to the mobile access + gateway that the Proxy Binding Update has been processed + successfully but GRE encapsulation and GRE keys are not required. + + GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3) + + If the local mobility anchor receives a Proxy Binding Update with + the GRE Key option and TLV-header format (T) flag set, the local + mobility anchor uses this code to indicate to the mobile access + gateway that GRE encapsulation has been successfully negotiated + but TLV-header format is NOT supported. + + GRE_KEY_OPTION_REQUIRED (163) + + When the local mobility anchor receives a Proxy Binding Update + without the GRE Key option while based on a policy check, the + local mobility anchor determines that GRE encapsulation is + required for this specific mobility session and uses this code to + reject the Proxy Binding Update and indicate to the mobile access + gateway that GRE encapsulation and GRE keys are required. + +7. Data Packets Processing Considerations + + This section describes how the local mobility anchor and mobile + access gateway encapsulate and decapsulate data packets when GRE + encapsulation and GRE keys are used for tunneling the mobile node's + data traffic between these two mobile nodes. + +7.1. Tunneling Format + + When GRE encapsulation is used, the mobile access gateway is allowed + to use various tunneling formats depending on the mobile access + gateway location and the network capabilities between the mobile + access gateway and the local mobility anchor. Using GRE + encapsulation, as described in [RFC2784] and [RFC2890], the mobile + access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or + in IPv4 following the rules in [RFC5213] and [RFC5844]. + + If UDP-based tunneling is used in conjunction with GRE encapsulation + between the mobile access gateway and the local mobility anchor, the + TLV-header UDP tunneling format as shown in Figure 5 MUST be used. + + + + + +Muhanna, et al. Standards Track [Page 15] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + [IPv4 Header] + + [UDP Header] + + [TLV Header] + + [GRE Header] + + [Payload - IPv6 or IPv4 Header] + + Upper Layer protocols + + Figure 5: TLV-Header UDP-Based Encapsulation Header Order + + When a UDP-based tunneling format is used between the mobile access + gateway and the local mobility anchor, the use of the TLV header is + negotiated during the Proxy Binding Update/Acknowledgement exchange + as described in Sections 7.3 and 7.4. If the TLV-header format is + agreed upon between the mobile access gateway and local mobility + anchor, the local mobility anchor expects the TLV header to follow + the UDP header as shown in Figure 5. The TLV header contains the + Type field, the following payload packet header type, and its length. + The Type field in the TLV header is always set to a value of 0 to + enhance the processing of the received packet by ensuring that the + receiver can differentiate whether what came after the UDP header is + a TLV-header Type field or an IP version field of an IP header. + Hence, the TLV header can carry traffic other than IP as indicated in + the Next Header field. The distinction between IP and TLV + encapsulation is needed, because the Proxy Binding Update (IP packet) + and the data packets (GRE packets) can be sent over the same UDP + tunnel. + + When processing a UDP packet with the TLV-header format, if the + receiving node found that the payload packet length as calculated + from the UDP header length field is different than its length as + calculated from the TLV-header length field, the receiving node MUST + discard the received IP packet. + +7.2. TLV-Header Tunneling Negotiation + + The mobile access gateway negotiates the format for tunneling payload + traffic during the Proxy Mobile IPv6 registration procedure. If the + mobile access gateway is required to use the TLV-header UDP + encapsulation format, the mobile access gateway MUST set the TLV- + header format (T) flag in the Proxy Binding Update message sent to + the local mobility anchor. If the local mobility anchor supports the + TLV-header UDP tunneling format, the local mobility anchor SHOULD set + the TLV-header format (T) flag in the Proxy Binding Acknowledgement. + + + +Muhanna, et al. Standards Track [Page 16] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + Otherwise, the TLV-header format (T) flag is cleared. The setting of + the TLV-header Format (T) flag in the Proxy Binding Acknowledgement + indicates to the mobile access gateway that it MUST use the TLV- + header UDP encapsulation format for all packets tunneled to the local + mobility anchor for the entire duration the mobile node is attached + to the mobile access gateway. The TLV-header UDP tunneling format + SHOULD NOT change during a Binding Lifetime Extension Proxy Binding + Update (re-registration) from the same mobile access gateway. + + Any Proxy Binding Update message triggered by a handoff (Section + 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, + in order to avoid interoperability issues, the local mobility anchor + MUST NOT set the TLV-header format (T) flag unless it was set in the + Proxy Binding Update received from the mobile access gateway. + + The TLV-header format is as shown below in Figure 6. + + 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 | Res. | Next Header | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: TLV-Header Format + + Type + + This field is always 0 (zero) and distinguishes the TLV header + from the IPv4 and IPv6 headers. + + Res. + + These fields are Reserved and unused. They MUST be initialized to + zero by the sender and MUST be ignored by the receiver. + + Next Header + + An 8-bit unsigned integer that indicates the protocol number of + the payload header following this TLV header. It is set to the + protocol number as assigned by IANA in the "Assigned Internet + Protocol Numbers" registry. For example, if an IPv6 header + follows, it should be '41'; if a GRE header follows, it should be + '47'. + + Length + + A 16-bit unsigned integer indicating the length in octets of the + payload following this header, excluding the TLV header itself. + + + +Muhanna, et al. Standards Track [Page 17] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + +7.3. Mobile Access Gateway Operation + + When sending a Proxy Binding Update message over an IPv4 transport + network, the mobile access gateway follows the procedures specified + in [RFC5844] for using IPv4-UDP encapsulation mode. However, when + using GRE header in conjunction with IPv4-UDP encapsulation mode is + required, the mobile access gateway MUST set the TLV-header format + (T) flag in the Proxy Binding Update and follow this specification + for GRE encapsulation negotiation. If the received Proxy Binding + Acknowledgement is successful and the TLV-header format (T) flag is + set and the GRE Key option included, the mobile access gateway MUST + update the mobile node's Binding Update List entry described in + Section 4.1 by setting the UDP-based TLV-header format (T) flag. In + this case, the mobile access gateway MUST use the TLV-header UDP- + based encapsulation format as shown in Figure 5. + + If the mobile access gateway receives a Proxy Binding Acknowledgement + with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in + response to a Proxy Binding Update with the GRE Key option and the + (T) flag set, the mobile access gateway MUST use GRE encapsulation + without UDP encapsulation. If the mobile access gateway is allowed + to use GRE encapsulation without UDP tunneling, the mobile access + gateway MUST update the mobile node's Binding Update List entry + described in Section 4.1 by setting the GRE-encapsulation-enabled + flag and the uplink and downlink GRE key fields. In this case, the + mobile access gateway MUST set the UDP-based TLV-header format (T) + flag to FALSE. A Proxy Binding Acknowledgement message with the + status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T) + flag cleared. Alternatively, the mobile access gateway may resend + the Proxy Binding Update to negotiate different tunneling options, + e.g., using UDP-based tunneling without GRE encapsulation if possible + or de-register the mobile node mobility session. + +7.3.1. Sending and Receiving Data Packets + + When the mobile access gateway is located in an IPv6-enabled or IPv4- + enabled network, it may be required to use GRE encapsulation for + tunneling IPv6 or IPv4 data packets to the local mobility anchor. In + this case, and if the mobile access gateway has successfully + negotiated GRE encapsulation mode only or GRE encapsulation and GRE + keys as described in this specification, the mobile access gateway + encapsulates or decapsulates IPv6-or-IPv4 payload packets following + the rules described in [RFC5213] and [RFC5844] while ensuring that + the GRE header is present as shown in Figure 7. + + + + + + + +Muhanna, et al. Standards Track [Page 18] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + [IPv6 or IPv4 Header] + + [GRE Header] + + [Payload - IPv6 or IPv4 Header] + + Upper Layer protocols + + Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation + + On the other hand, if the mobile access gateway is located in an + IPv4-only network where NAT has been detected on the path between the + mobile access gateway and the local mobility anchor and successfully + negotiated GRE encapsulation and the TLV-header format, the mobile + access gateway MUST use UDP TLV-header tunneling format when sending + an IPv6-or-IPv4 payload packet to the local mobility anchor according + to the format described in Figure 5. The source and the destination + of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address, + IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4- + LMAA, respectively. In addition, the source and the destination IP + addresses of the IPv6-or-IPv4 payload data packet are the mobile + node's IPv6-or-IPv4 home address, IPv6/IPv4-MN-HoA, and the IPv6-or- + IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, respectively. + +7.4. Local Mobility Anchor Operation + + When the local mobility anchor receives a Proxy Binding Update + encapsulated in UDP and containing the IPv4 Home Address Request + option ([RFC5844]), it needs to follow all the steps in [RFC5213] and + [RFC5844]. In addition, if the TLV-header format (T) flag is set in + the Proxy Binding Update, the local mobility anchor needs to + determine whether it can accept the TLV-header UDP-based + encapsulation format. If it does, it SHOULD set the TLV-header + format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the + local mobility anchor MUST NOT set the TLV-header format (T) flag in + the Proxy Binding Acknowledgement. + + If the local mobility anchor (LMA) receives a Proxy Binding Update + with the GRE Key option and TLV-header format (T) flag set and, based + on a policy check, the LMA determines that GRE encapsulation is + required and the LMA supports TLV-header tunneling and the LMA sent a + successful Proxy Binding Acknowledgement with the TLV-header format + (T) flag set, the LMA MUST update the mobile node's Binding Cache + entry described in Section 5.1 by setting the GRE-encapsulation- + enabled flag and update the uplink and downlink GRE key fields. In + addition, the LMA MUST set the UDP-based TLV-header format flag. + + + + + +Muhanna, et al. Standards Track [Page 19] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + + If the LMA receives a Proxy Binding Update with the GRE Key option + and TLV-header format (T) flag set and, based on a policy check, the + LMA determines that GRE encapsulation is required BUT the LMA does + NOT support TLV-header tunneling and if the Proxy Binding Update has + been successfully processed, the LMA MUST send a successful Proxy + Binding Acknowledgement with the status code + GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED. This way, the LMA + indicates to the mobile access gateway that GRE encapsulation has + been successfully negotiated BUT TLV-header UDP-based tunneling + format is not supported. In this case, the LMA MUST update the + mobile node's BCE described in Section 5.1 by setting the GRE + encapsulation enabled flag and update the uplink and downlink GRE key + fields. In this case, the LMA MUST set the UDP-based TLV-header + format flag to FALSE. + + If the local mobility anchor and the mobile access gateway have + successfully negotiated the TLV-header UDP-based tunneling format and + GRE encapsulation for a specific mobility session, the local mobility + anchor processes data packets as described in the following + subsection. + +7.4.1. Sending and Receiving Data Packets + + The local mobility anchor may use GRE encapsulation for tunneling an + IPv6 or IPv4 data packet to the mobile access gateway. If the local + mobility anchor has successfully negotiated GRE encapsulation with + the mobile access gateway for a specific mobility session, the local + mobility anchor encapsulates and decapsulates IPv6-or-IPv4 payload + data packets following the rules described in [RFC5213] and [RFC5844] + while ensuring that the GRE header is present as shown in Figure 7. + + In the case when TLV-tunneling format and GRE encapsulation for a + specific mobility session have been successfully negotiated between + the local mobility anchor and the mobile access gateway, the local + mobility anchor follows the TLV-header UDP-based tunneling format and + header order as shown in Figure 5 to encapsulate IPv4 or IPv6 payload + packets in IPv4 before sending the IPv4 packet to the mobile access + gateway. In this case, the source and the destination of the IPv4 + outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In + addition, the source and the destination IP addresses of the IPv6-or- + IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA, + respectively. On the other hand, the local mobility anchor ensures + the same TLV-header UDP-based tunneling format and header order when + it decapsulates received IPv4 packets from the mobile access gateway + for the same mobility session. + + + + + + +Muhanna, et al. Standards Track [Page 20] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + +8. IANA Considerations + + This specification defines a new mobility option, the GRE Key option, + described in Section 6.1. This option is carried in the Mobility + Header. The type value for this option has been assigned from the + same numbering space as allocated for the other mobility options + defined in the Mobile IPv6 specification [RFC3775]. + + This specification also defines three new Binding Acknowledgement + status codes as described in Section 6.4 and IANA has allocated the + numeric values as specified in Section 6.4 from the "Status Codes" + registry of the Mobility IPv6 Parameters. + +9. Security Considerations + + The GRE Key option, defined in this specification, when carried in + Proxy Binding Update and Proxy Binding Acknowledgement messages, + reveals the group affiliation of a mobile node identified by its + Network Access Identifier (NAI) or an IP address. It may help an + attacker in targeting flows belonging to a specific group. This + vulnerability can be prevented, by enabling confidentiality + protection on the Proxy Binding Update and Proxy Binding + Acknowledgement messages where the presence of the NAI and GRE Key + options establish a mobile node's relation to a specific group. This + vulnerability can also be avoided by enabling confidentiality + protection on all the tunneled data packets between the mobile access + gateway and the local mobility anchor, for hiding all the markings. + + In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for + protecting a mobile node's data traffic is optional. Additionally, + Proxy Mobile IPv6 recommends the use of Encapsulating Security + Payload (ESP) [RFC4303] in tunnel mode when using ESP for protecting + the mobile node's data traffic. However, when GRE encapsulation is + used, both IPsec tunnel mode and transport mode can be used to + protect the GRE header. The IPsec traffic selectors will contain the + protocol number for GRE, and there is currently no mechanism to use + the GRE key as a traffic selector. + +10. Acknowledgements + + The authors would like to thank Alessio Casati, Barney Barnowski, + Mark Grayson, and Parviz Yegani for their input on the need for this + option. The authors would like to thank Charlie Perkins, Curtis + Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal + Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review + and comments. + + + + + +Muhanna, et al. Standards Track [Page 21] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + +11. References + +11.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + March 2000. + + [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", + RFC 2890, September 2000. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [RFC5213] Gundavelli, S., 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. + +11.2. Informative References + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., + and K. Nagami, "Multiple Care-of Addresses Registration", + RFC 5648, October 2009. + + + + + + + +Muhanna, et al. Standards Track [Page 22] + +RFC 5845 GRE Key Option for Proxy MIPv6 June 2010 + + +Authors' Addresses + + Ahmad Muhanna + Ericsson, Inc. + 2201 Lakeside Blvd. + Richardson, TX 75082 + USA + + EMail: ahmad.muhanna@ericsson.com + + + Mohamed Khalil + Ericsson, Inc. + 6300 Legacy Dr. + Plano, TX 75024 + USA + + EMail: Mohamed.khalil@ericsson.com + + + Sri Gundavelli + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: sgundave@cisco.com + + + Kent Leung + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: kleung@cisco.com + + + + + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 23] + |