doc: Add RFC documents

1 files changed, 315 insertions, 0 deletions

diff --git a/doc/rfc/rfc8983.txt b/doc/rfc/rfc8983.txt
new file mode 100644
index 0000000..406b7d9
--- /dev/null
+++ b/doc/rfc/rfc8983.txt
@@ -0,0 +1,315 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 8983                                        Orange
+Updates: 7296                                              February 2021
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+  Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status
+                    Types for IPv4/IPv6 Coexistence
+
+Abstract
+
+   This document specifies new Internet Key Exchange Protocol Version 2
+   (IKEv2) notification status types to better manage IPv4 and IPv6
+   coexistence by allowing the responder to signal to the initiator
+   which address families are allowed.
+
+   This document updates RFC 7296.
+
+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 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8983.
+
+Copyright Notice
+
+   Copyright (c) 2021 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
+   (https://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
+   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
+   2.  Terminology
+   3.  Why Not INTERNAL_ADDRESS_FAILURE?
+   4.  IP6_ALLOWED and IP4_ALLOWED Status Types
+   5.  Update to RFC 7296
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   As described in [RFC7849], if the subscription data or network
+   configuration allows only one IP address family (IPv4 or IPv6), the
+   cellular host must not request a second PDP-Context (Section 3.2 of
+   [RFC6459]) to the same Access Point Name (APN) for the other IP
+   address family (AF).  The Third Generation Partnership Project (3GPP)
+   network informs the cellular host about allowed Packet Data Protocol
+   (PDP) types by means of Session Management (SM) cause codes.  In
+   particular, the following cause codes can be returned:
+
+   cause #50 "PDP type IPv4 only allowed":  This cause code is used by
+      the network to indicate that only PDP type IPv4 is allowed for the
+      requested Public Data Network (PDN) connectivity.
+
+   cause #51 "PDP type IPv6 only allowed":  This cause code is used by
+      the network to indicate that only PDP type IPv6 is allowed for the
+      requested PDN connectivity.
+
+   cause #52 "single address bearers only allowed":  This cause code is
+      used by the network to indicate that the requested PDN
+      connectivity is accepted with the restriction that only single IP
+      version bearers are allowed.
+
+   If the requested IPv4v6 PDP-Context is not supported by the network
+   but IPv4 and IPv6 PDP types are allowed, then the cellular host will
+   be configured with an IPv4 address or an IPv6 prefix by the network.
+   It must initiate another PDP-Context activation of the other address
+   family in addition to the one already activated for a given APN.  The
+   purpose of initiating a second PDP-Context is to achieve dual-stack
+   connectivity (that is, IPv4 and IPv6 connectivity) by means of two
+   PDP-Contexts.
+
+   When the User Equipment (UE) attaches to the 3GPP network using a
+   non-3GPP access network (e.g., Wireless Local Area Network (WLAN)),
+   there are no equivalent IKEv2 capabilities [RFC7296] notification
+   codes for the 3GPP network to inform the UE why an IP address family
+   is not assigned or whether that UE should retry with another address
+   family.
+
+   This document fills that void by introducing new IKEv2 notification
+   status types for the sake of deterministic UE behaviors (Section 4).
+
+   These notification status types are not specific to 3GPP
+   architectures but can be used in other deployment contexts.  Cellular
+   networks are provided as an illustration example.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document makes use of the terms defined in [RFC7296].  In
+   particular, readers should be familiar with "initiator" and
+   "responder" terms used in that document.
+
+3.  Why Not INTERNAL_ADDRESS_FAILURE?
+
+   The following address assignment failures may be encountered when an
+   initiator requests assignment of IP addresses/prefixes:
+
+   *  An initiator asks for IPvx, but IPvx address assignment is not
+      supported by the responder.
+
+   *  An initiator requests both IPv4 and IPv6 addresses, but only IPv4
+      address assignment is supported by the responder.
+
+   *  An initiator requests both IPv4 and IPv6 addresses, but only IPv6
+      prefix assignment is supported by the responder.
+
+   *  An initiator asks for both IPv4 and IPv6 addresses, but only one
+      address family can be assigned by the responder for policy
+      reasons.
+
+   Section 3.15.4 of [RFC7296] defines a generic notification error type
+   (INTERNAL_ADDRESS_FAILURE) that is related to a failure to handle an
+   address assignment request.  The responder sends
+   INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.  This
+   behavior does not explicitly allow an initiator to determine why a
+   given address family is not assigned, nor whether it should try using
+   another address family.  INTERNAL_ADDRESS_FAILURE is a catch-all
+   error type when an address-related issue is encountered by an IKEv2
+   responder.
+
+   INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the
+   IKEv2 initiator to adjust its behavior.
+
+4.  IP6_ALLOWED and IP4_ALLOWED Status Types
+
+   IP6_ALLOWED and IP4_ALLOWED notification status types (see Section 7)
+   are defined to inform the initiator about the responder's address
+   family assignment support capabilities and to report to the initiator
+   the reason why an address assignment failed.  These notification
+   status types are used by the initiator to adjust its behavior
+   accordingly (Section 5).
+
+   No data is associated with these notifications.
+
+5.  Update to RFC 7296
+
+   If the initiator is dual stack (i.e., supports both IPv4 and IPv6),
+   it MUST include configuration attributes for both address families in
+   its configuration request (absent explicit policy/configuration
+   otherwise).  More details about IPv4 and IPv6 configuration
+   attributes are provided in Section 3.15 of [RFC7296].  These
+   attributes are used to infer the requested/assigned AFs listed in
+   Table 1.
+
+   The responder MUST include the IP6_ALLOWED and/or IP4_ALLOWED
+   notification status type in a response to an address assignment
+   request as indicated in Table 1.
+
+    +=============+==============+=============+=====================+
+    | Requested   | Supported    | Assigned    | Returned            |
+    | AF(s)       | AF(s)        | AF(s)       | Notification Status |
+    | (Initiator) | (Responder)  | (Responder) | Type(s) (Responder) |
+    +=============+==============+=============+=====================+
+    | IPv4        | IPv6         | None        | IP6_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4        | IPv4         | IPv4        | IP4_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4        | IPv4 and     | IPv4        | IP4_ALLOWED,        |
+    |             | IPv6         |             | IP6_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv6        | IPv6         | IPv6        | IP6_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv6        | IPv4         | None        | IP4_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv6        | IPv4 and     | IPv6        | IP4_ALLOWED,        |
+    |             | IPv6         |             | IP6_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4 and    | IPv4         | IPv4        | IP4_ALLOWED         |
+    | IPv6        |              |             |                     |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4 and    | IPv6         | IPv6        | IP6_ALLOWED         |
+    | IPv6        |              |             |                     |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4 and    | IPv4 and     | IPv4 and    | IP4_ALLOWED,        |
+    | IPv6        | IPv6         | IPv6        | IP6_ALLOWED         |
+    +-------------+--------------+-------------+---------------------+
+    | IPv4 and    | IPv4 or IPv6 | IPv4 or     | IP4_ALLOWED,        |
+    | IPv6        | (policy      | IPv6        | IP6_ALLOWED         |
+    |             | based)       |             |                     |
+    +-------------+--------------+-------------+---------------------+
+
+               Table 1: Returned Notification Status Types
+
+   If the initiator only receives one single IP4_ALLOWED or IP6_ALLOWED
+   notification from the responder, the initiator MUST NOT send a
+   subsequent request for an alternate address family not supported by
+   the responder.
+
+   If a dual-stack initiator requests only an IPv6 prefix (or an IPv4
+   address) but only receives an IP4_ALLOWED (or IP6_ALLOWED)
+   notification status type from the responder, the initiator MUST send
+   a request for IPv4 address(es) (or IPv6 prefix(es)).
+
+   If a dual-stack initiator requests both an IPv6 prefix and an IPv4
+   address but receives an IPv6 prefix (or an IPv4 address) only with
+   both IP4_ALLOWED and IP6_ALLOWED notification status types from the
+   responder, the initiator MAY send a request for the other AF (i.e.,
+   IPv4 address (or IPv6 prefix)).  In such case, the initiator MUST
+   create a new IKE Security Association (SA) and request another
+   address family using the new IKE SA.
+
+   For other address-related error cases that have not been covered by
+   the aforementioned notification status types, the responder/initiator
+   MUST follow the procedure defined in Section 3.15.4 of [RFC7296].
+
+6.  Security Considerations
+
+   Since the IPv4/IPv6 capabilities of a node are readily determined
+   from the traffic it generates, this document does not introduce any
+   new security considerations compared to the ones described in
+   [RFC7296], which continue to apply.
+
+7.  IANA Considerations
+
+   IANA has updated the "IKEv2 Notify Message Types - Status Types"
+   registry (available at <https://www.iana.org/assignments/
+   ikev2-parameters/>) with the following status types:
+
+          +=======+================================+===========+
+          | Value | NOTIFY MESSAGES - STATUS TYPES | Reference |
+          +=======+================================+===========+
+          | 16439 | IP4_ALLOWED                    | RFC 8983  |
+          +-------+--------------------------------+-----------+
+          | 16440 | IP6_ALLOWED                    | RFC 8983  |
+          +-------+--------------------------------+-----------+
+
+            Table 2: Updates to "IKEv2 Notify Message Types -
+                          Status Types" Registry
+
+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>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+              2014, <https://www.rfc-editor.org/info/rfc7296>.
+
+   [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
+
+   [RFC6459]  Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
+              T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
+              Partnership Project (3GPP) Evolved Packet System (EPS)",
+              RFC 6459, DOI 10.17487/RFC6459, January 2012,
+              <https://www.rfc-editor.org/info/rfc6459>.
+
+   [RFC7849]  Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
+              N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
+              "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
+              DOI 10.17487/RFC7849, May 2016,
+              <https://www.rfc-editor.org/info/rfc7849>.
+
+Acknowledgements
+
+   Many thanks to Christian Jacquenet for the review.
+
+   Thanks to Paul Wouters, Yaov Nir, Valery Smyslov, Daniel Migault,
+   Tero Kivinen, and Michael Richardson for the comments and review.
+
+   Thanks to Benjamin Kaduk for the AD review.
+
+   Thanks to Murray Kucherawy, Éric Vyncke, and Robert Wilton for the
+   IESG review.
+
+Author's Address
+
+   Mohamed Boucadair
+   Orange
+   35000 Rennes
+   France
+
+   Email: mohamed.boucadair@orange.com