doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7225.txt b/doc/rfc/rfc7225.txt
new file mode 100644
index 0000000..d5c265d
--- /dev/null
+++ b/doc/rfc/rfc7225.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 7225                                France Telecom
+Category: Standards Track                                       May 2014
+ISSN: 2070-1721
+
+
+ Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
+
+Abstract
+
+   This document defines a new Port Control Protocol (PCP) option to
+   learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to
+   build IPv4-converted IPv6 addresses.  This option is needed for
+   successful communications when IPv4 addresses are used in referrals.
+
+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/rfc7225.
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   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.
+
+
+
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 1]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
+   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
+     3.1.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     3.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   3
+       3.2.1.  AAAA Synthesis by the DNS Stub-resolver . . . . . . .   4
+       3.2.2.  Application Referrals . . . . . . . . . . . . . . . .   4
+   4.  PREFIX64 Option . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.2.  Server's Behavior . . . . . . . . . . . . . . . . . . . .   7
+     4.3.  Client's Behavior . . . . . . . . . . . . . . . . . . . .   9
+   5.  Flow Examples . . . . . . . . . . . . . . . . . . . . . . . .  10
+     5.1.  TCP Session Initiated from an IPv6-only Host  . . . . . .  10
+     5.2.  SIP Flow Example  . . . . . . . . . . . . . . . . . . . .  11
+     5.3.  Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . .  13
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
+
+1.  Introduction
+
+   According to [RFC6146], NAT64 uses Pref64::/n to construct
+   IPv4-converted IPv6 addresses as defined in [RFC6052].
+
+   This document defines a new Port Control Protocol (PCP) option
+   [RFC6887] to inform PCP clients about the Pref64::/n and suffix
+   [RFC6052] used by a PCP-controlled NAT64 device [RFC6146].  It does
+   so by defining a new PREFIX64 option.
+
+   This PCP option is a deterministic solution to help establish
+   communications between IPv6-only hosts and remote IPv4-only hosts.
+   Unlike [RFC7050], this option solves all the issues identified in
+   [RFC7051].
+
+   Some illustrative examples are provided in Section 5.  Detailed
+   experiments conducted to assess the applicability of the PREFIX64
+   option for services (e.g., accessing a video server, establishing
+   SIP-based sessions, etc.) in NAT64 environments are available in
+   [EXPERIMENTS].
+
+   The use of this PCP option for NAT64 load-balancing purposes is out
+   of scope.
+
+
+
+
+Boucadair                    Standards Track                    [Page 2]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+2.  Requirements Language
+
+   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
+   [RFC2119].
+
+3.  Problem Statement
+
+3.1.  Issues
+
+   This document proposes a deterministic solution to solve the
+   following issues:
+
+   o  Learn the Pref64::/n used by an upstream NAT64 function.  This is
+      needed to help:
+      *  distinguish between IPv4-converted IPv6 addresses [RFC6052] and
+         native IPv6 addresses.
+      *  implement IPv6 address synthesis for applications not relying
+         on DNS (where DNS64 [RFC6147] would provide the synthesis).
+
+   o  Avoid stale Pref64::/n values.
+
+   o  Discover multiple Pref64::/n values when multiple prefixes exist
+      in a network.
+
+   o  Use DNSSEC ([RFC4033], [RFC4034], [RFC4035]) in the presence of
+      NAT64.
+
+   o  Discover the suffix used by a NAT64 function when non-null
+      suffixes are in use (e.g., checksum neutral suffix).
+
+   o  Support destination-based Pref64::/n (e.g., Section 5.1 of
+      [RFC7050]).
+
+   o  Associate a Pref64::/n with a given NAT64 when distinct prefixes
+      are configured for each NAT64 enabled in a network.
+
+   A more extensive discussion can be found at [RFC7051].
+
+3.2.  Use Cases
+
+   This section provides some use cases to illustrate the problem space.
+   More details can be found at Section 4 of [RFC7051].
+
+
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 3]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+3.2.1.  AAAA Synthesis by the DNS Stub-Resolver
+
+   The option defined in this document can be used for hosts with DNS64
+   capability [RFC6147] added to the host's stub-resolver.
+
+   The stub resolver on the host will try to obtain (native) AAAA
+   records, and if they are not found, the DNS64 function on the host
+   will query for A records and then synthesize AAAA records.  Using the
+   PREFIX64 PCP extension, the host's stub-resolver can learn the prefix
+   used for IPv6/IPv4 translation and synthesize AAAA records
+   accordingly.
+
+   Because synthetic AAAA records cannot be successfully validated in a
+   host, learning the Pref64::/n used to construct IPv4-converted IPv6
+   addresses allows the use of DNSSEC.  As discussed in Section 5.5 of
+   [RFC6147], a security-aware and validating host has to perform the
+   DNS64 function locally.
+
+3.2.2.  Application Referrals
+
+   As discussed in [REF-OBJECT], a frequently occurring situation is
+   that one entity A connected to a network needs to inform another
+   entity B how to reach either A itself or some third-party entity C.
+   This is known as address referral.
+
+   In the particular context of NAT64 [RFC6146], applications relying on
+   address referral will fail because an IPv6-only client won't be able
+   to make use of an IPv4 address received in a referral.  A non-
+   exhaustive list of such applications is provided below:
+
+   o  In SIP environments [RFC3261], the SDP part ([RFC4566]) of
+      exchanged SIP messages includes information required for
+      establishing RTP sessions (namely, IP address and port number).
+      When a NAT64 is involved in the path, an IPv6-only SIP User Agent
+      (UA) that receives an SDP offer/answer containing an IPv4 address
+      cannot send media streams to the remote endpoint.
+
+   o  An IPv6-only WebRTC (Web Real-Time Communication [WebRTC]) agent
+      cannot make use of an IPv4 address received in referrals to
+      establish a successful session with a remote IPv4-only WebRTC
+      agent.
+
+   o  BitTorrent is a distributed file-sharing infrastructure that is
+      based on peer-to-peer (P2P) techniques for exchanging files
+      between connected users.  To download a given file, a BitTorrent
+      client needs to obtain the corresponding torrent file.  Then, it
+      connects to a tracker to retrieve a list of "leechers" (clients
+      that are currently downloading the file but do not yet possess all
+
+
+
+Boucadair                    Standards Track                    [Page 4]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+      portions of the file) and "seeders" (clients that possess all
+      portions of the file and are uploading them to other requesting
+      clients).  The client connects to those machines and downloads the
+      available portions of the requested file.  In the presence of an
+      address-sharing function (see Appendix A of [RFC6269]), some
+      encountered issues are solved if PCP is enabled (see
+      [PCP-BITTORRENT]).  Nevertheless, an IPv6-only client cannot
+      connect to a remote IPv4-only machine even if the base PCP
+      protocol is used.
+
+      Learning the Pref64::/n solves the issues listed above.
+
+4.  PREFIX64 Option
+
+4.1.  Format
+
+      The format of the PREFIX64 option is depicted in Figure 1.  This
+      option follows the guidelines specified in Section 7.3 of
+      [RFC6887].
+
+      This option allows the mapping of specific IPv4 address ranges
+      (contained in the IPv4 Prefix List) to separate Pref64::/n
+      prefixes as discussed in [RFC6147].
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Option Code=129|  Reserved     |        Option Length          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Prefix64  Length           |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      :                      Prefix64 (Variable)                      :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      :                    Suffix (Variable)                          :
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       (optional)                              |
+      :               IPv4 Prefix List (Variable)                     :
+      |                      (See Figure 2)                           |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 1: Prefix64 PCP Option
+
+
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 5]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   The description of the fields is as follows:
+
+   o  Option Code: 129
+
+   o  Reserved: This field is initialized as specified in Section 7.3 of
+      [RFC6887].
+
+   o  Option Length: Indicates in octets the length of the enclosed
+      data.
+
+   o  Prefix64 Length: Indicates in octets the length of the Pref64::/n.
+      The allowed values are specified in [RFC6052] (i.e., 4, 5, 6, 7,
+      8, or 12).
+
+   o  Prefix64: This field identifies the IPv6 unicast prefix to be used
+      for constructing an IPv4-converted IPv6 address from an IPv4
+      address as specified in Section 2.2 of [RFC6052].  This prefix can
+      be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-
+      Specific Prefix.  The address synthesis MUST follow the guidelines
+      documented in [RFC6052].
+
+   o  Suffix: The length of this field is (12 - Prefix64 Length) octets.
+      This field identifies the suffix to be used for constructing an
+      IPv4-converted IPv6 address from an IPv4 address as specified in
+      Section 2.2 of [RFC6052].  No suffix is included if a /96 Prefix64
+      is conveyed in the option.
+
+   o  IPv4 Prefix List: This is an optional field.  The format of the
+      IPv4 Prefix List field is shown in Figure 2.  This field may be
+      included by a PCP server to solve the destination-dependent
+      Pref64::/n discovery problem discussed in Section 5.1 of
+      [RFC7050].
+      *  IPv4 Prefix Count: indicates the number of IPv4 prefixes
+         included in the option.  "IPv4 Prefix Count" field MUST be set
+         to 0 in a request and MUST be set to the number of included
+         IPv4 subnets in a response.
+      *  An IPv4 prefix is represented as "IPv4 Address/IPv4 Prefix
+         Length" [RFC4632].  For example, to encode 192.0.2.0/24, "IPv4
+         Prefix Length" field is set to 24 and "IPv4 Address" field is
+         set to 192.0.2.0.  If a Pref64::/n is configured for all IPv4
+         addresses, a wildcard IPv4 prefix (i.e., 0.0.0.0/0) may be
+         returned in the response together with the configured
+         Pref64::/n.  If no IPv4 Prefix List is returned in a PREFIX64
+         option, the PCP client assumes the prefix is valid for any
+         destination IPv4 address.  Valid IPv4 prefixes are listed in
+         Section 3.1 of [RFC4632].
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 6]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      IPv4 Prefix Count        |      IPv4 Prefix Length       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     IPv4 Address (32 bits)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   .                           ....                                .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      IPv4 Prefix Length       |   IPv4 Address (32 bits)...   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  ... IPv4 Address (continued) |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 2: Format of IPv4 Prefix List field
+
+      Option Name: PREFIX64
+
+      Value: 129
+
+      Purpose: Learn the prefix used by the NAT64 to build
+         IPv4-converted IPv6 addresses.  This is used by a host for
+         local address synthesis (e.g., when an IPv4 address is present
+         in referrals).
+
+      Valid for Opcodes: MAP, ANNOUNCE
+
+      Length: Variable
+
+      May appear in: request, response.
+
+      Maximum occurrences: 1 for a request.  As many as fit within the
+         maximum PCP message size for a response.
+
+4.2.  Server's Behavior
+
+   The PCP server controlling a NAT64 SHOULD be configured to return to
+   requesting PCP clients the value of the Pref64::/n and suffix used to
+   build IPv4-converted IPv6 addresses.  When enabled, the PREFIX64
+   option conveys the value of the Pref64::/n and configured suffix.  If
+   no suffix is explicitly configured to the PCP server, the null suffix
+   is used as the default value (see Section 2.2 of [RFC6052]).
+
+   If the PCP server is configured to honor the PREFIX64 option but no
+   Pref64::/n is explicitly configured, the PCP server MUST NOT include
+   any PREFIX64 option in its PCP messages.
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 7]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   The PCP server controlling a NAT64 MAY be configured to include a
+   PREFIX64 option in all MAP responses even if the PREFIX64 option is
+   not listed in the associated request.  The PCP server controlling a
+   NAT64 MAY be configured to include a PREFIX64 option in its ANNOUNCE
+   messages.
+
+   The PCP server MAY be configured with a list of destination IPv4
+   prefixes associated with a Pref64::/n.  This list is then included by
+   the PCP server in a PREFIX64 option sent to PCP clients.
+
+   The PCP server MAY be configured to return multiple PREFIX64 options
+   in the same message to the PCP client.  In such case, the server does
+   the following:
+
+   o  If no destination IPv4 prefix list is configured, the PCP server
+      includes in the first PREFIX64 option, which appears in the PCP
+      message it sends to the PCP client, the prefix and suffix to
+      perform local IPv6 address synthesis [RFC6052].  Additional
+      PREFIX64 options convey any other Pref64::/n values configured.
+      Returning these prefixes allows an end host to identify all
+      synthesized IPv6 addresses in a network; the host can prefer IPv4
+      or another network interface instead in order to avoid any NAT64
+      deployed in the network.  The PCP server is required to
+      disambiguate prefixes used for IPv6 address synthesis and other
+      prefixes used to avoid any NAT64 deployed in the network.  The PCP
+      server can be configured with a customized IPv6 prefix list (i.e.,
+      specific to a PCP client or a group of PCP clients) or system-wide
+      IPv6 prefix list (i.e., the same list is returned for any PCP
+      client).  Note, it is NOT RECOMMENDED to include PREFIX64 options
+      in ANNOUNCE messages if a customized IPv6 prefix list is
+      configured to the PCP server.
+
+   o  If IPv4 prefix lists are configured, the PCP server includes in
+      the first PREFIX64 options the Pref64::/n and suffix that are
+      associated with an IPv4 prefix list (i.e., each of these PREFIX64
+      options conveys a distinct Pref64::/n together with an IPv4 prefix
+      list).  Additional PREFIX64 options convey any other Pref64::/n
+      values configured (i.e., the remaining Pref64::/n values not
+      mapped to any IPv4 prefix list).
+
+   If a distinct Pref64::/n or suffix is configured to the PCP-
+   controlled NAT64 device, the PCP server SHOULD issue an unsolicited
+   PCP ANNOUNCE message to inform the PCP client about the new
+   Pref64::/n and/or suffix.
+
+
+
+
+
+
+
+Boucadair                    Standards Track                    [Page 8]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+4.3.  Client's Behavior
+
+   The PCP client includes a PREFIX64 option in a MAP or ANNOUNCE
+   request to learn the IPv6 prefix and suffix used by an upstream PCP-
+   controlled NAT64 device.  When enclosed in a PCP request, the
+   Prefix64 MUST be set to ::/96.  The PREFIX64 option can be inserted
+   in a MAP request used to learn the external IP address as detailed in
+   Section 11.6 of [RFC6887].
+
+   The PCP client MUST be prepared to receive multiple prefixes (e.g.,
+   if several PCP servers are deployed and each of them is configured
+   with a distinct Pref64::/n).  The PCP client MUST associate each
+   received Pref64::/n and suffix with the PCP server from which the
+   Pref64::/n and suffix information was retrieved.
+
+   If the PCP client fails to contact a given PCP server, the PCP client
+   SHOULD clear the prefix(es) and suffix(es) it learned from that PCP
+   server.  For example, a PCP client may fail to contact a PCP server
+   if the host embedding the PCP client moves to a new network or if
+   that PCP server is out of service.  The use of these stale prefixes
+   is not recommended to build an IPv4-converted IPv6 address because
+   failures are likely to be encountered (see [RFC7051], Section 3,
+   Issue #4).
+
+   If the PCP client receives a PREFIX64 option that includes an invalid
+   IPv4 prefix, the PCP client ignores that IPv4 prefix.  If one or more
+   valid IPv4 prefixes and/or IPv6 prefixes and suffixes are present,
+   the PCP client uses them.
+
+   Upon receipt of the message from the PCP server, the PCP client
+   replaces any old prefix(es)/suffix(es) received from the same PCP
+   server with the new one(s) included in the PREFIX64 option(s).  If no
+   PREFIX64 option includes a destination IPv4 prefix list, the host
+   embedding the PCP client uses the prefix/suffix included in the first
+   PREFIX64 option for local address synthesis.  Other prefixes learned
+   can be used by the host to avoid any NAT64 deployed in the network.
+   If one or multiple received PREFIX64 options contain a destination
+   IPv4 prefix list, the PCP client MUST associate the included IPv4
+   prefixes with the Pref64::/n and the suffix indicated in the same
+   PREFIX64 option.  In such case, the host embedding the PCP client
+   MUST enforce a destination-based prefix Pref64::/n selection for
+   local address synthesis purposes.  How the content of the PREFIX64
+   option(s) is passed to the OS is implementation specific.
+
+   Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client
+   replaces the old prefix/suffix received from the same PCP server with
+   the new Pref64::/n and suffix included in the PREFIX64 option.
+
+
+
+
+Boucadair                    Standards Track                    [Page 9]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+5.  Flow Examples
+
+   This section provides a non-normative description of use cases
+   relying on the PREFIX64 option.
+
+5.1.  TCP Session Initiated from an IPv6-Only Host
+
+   The usage shown in Figure 3 depicts a typical usage of the PREFIX64
+   option when a DNS64 capability is embedded in the host.
+
+   In the example shown in Figure 3, once the IPv6-only client discovers
+   the IPv4 address of the remote IPv4-only server (e.g., using DNS), it
+   retrieves the Pref64::/n (i.e., 2001:db8:122:300::/56) to be used to
+   build an IPv4-converted IPv6 address for that server.  This retrieval
+   is achieved using the PREFIX64 option (Steps (a) and (b)).  The
+   client then uses 2001:db8:122:300::/56 to construct an IPv6 address
+   and then initiates a TCP connection (Steps (1) to (4)).
+
+   +---------+              +-----+             +---------+
+   |IPv6-only|              |NAT64|             |IPv4-only|
+   | Client  |              |     |             |  Server |
+   +---------+              +-----+             +---------+
+       |                       |                     |
+       | (a) PCP MAP Request   |                     |
+       |      PREFIX64         |                     |
+       |======================>|                     |
+       | (b) PCP MAP Response  |                     |
+       |      PREFIX64 =       |                     |
+       | 2001:db8:122:300::/56 |                     |
+       |<======================|                     |
+       |    (1) TCP SYN        |    (2) TCP SYN      |
+       |======================>|====================>|
+       |   (4) TCP SYN/ACK     |   (3) TCP SYN/ACK   |
+       |<======================|<====================|
+       |    (5) TCP ACK        |    (6) TCP ACK      |
+       |======================>|====================>|
+       |                       |                     |
+
+   Note: The DNS exchange to retrieve the IPv4 address of
+         the IPv4-only Server is not shown in the figure.
+
+    Figure 3: Example of a TCP Session Initiated from an IPv6-Only Host
+
+
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 10]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+5.2.  SIP Flow Example
+
+   Figure 4 shows an example of the use of the option defined in Section
+   4 in a SIP context.  In order for RTP/RTCP flows to be exchanged
+   between an IPv6-only SIP UA and an IPv4-only UA without requiring any
+   ALG (Application Level Gateway) at the NAT64 or any particular
+   function at the IPv4-only SIP Proxy Server (e.g., hosted NAT
+   traversal [LATCHING]), the PORT_SET option [PORT-SET] is used in
+   addition to the PREFIX64 option.
+
+   In steps (a) and (b), the IPv6-only SIP UA retrieves a pair of ports
+   to be used for RTP/RTCP sessions, the external IPv4 address and the
+   Pref64::/n to build IPv4-embedded IPv6 addresses.  This is achieved
+   by issuing a MAP request that includes a PREFIX64 option and a
+   PORT_SET option.  A pair of ports (i.e., port_X/port_X+1) and an
+   external IPv4 address (together with a Pref64::/n, i.e.,
+   2001:db8:122::/48) are then returned by the PCP server to the
+   requesting PCP client.
+
+   The returned external IPv4 address and external port numbers are used
+   by the IPv6-only SIP UA to build its SDP offer, which contains
+   exclusively IPv4 addresses.  (Especially in the "c=" line, the port
+   indicated for the media port is the external port assigned by the PCP
+   server.)  The INVITE request including the SDP offer is then
+   forwarded by the NAT64 to the Proxy Server, which will relay it to
+   the called party, i.e., the IPv4-only SIP UA (Steps (1) to (3)).
+
+   The remote IPv4-only SIP UA accepts the offer and sends back its SDP
+   answer in a "200 OK" message that is relayed by the SIP Proxy Server
+   and NAT64 until being delivered to the IPv6-only SIP UA (Steps (4) to
+   (6)).
+
+   The Pref64::/n (2001:db8:122::/48) is used by the IPv6-only SIP UA to
+   construct a corresponding IPv6 address of the IPv4 address enclosed
+   in the SDP answer made by the IPv4-only SIP UA (Step (6)).
+
+   The IPv6-only SIP UA and IPv4-only SIP UA are then able to exchange
+   RTP/RTCP flows without requiring any ALG at the NAT64 or any special
+   function at the IPv4-only SIP Proxy Server.
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 11]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   +---------+              +-----+       +------------+     +---------+
+   |IPv6-only|              |NAT64|       |  IPv4 SIP  |     |IPv4-only|
+   | SIP UA  |              |     |       |Proxy Server|     | SIP UA  |
+   +---------+              +-----+       +------------+     +---------+
+       | (a) PCP MAP Request   |                |                 |
+       |        PORT_SET       |                |                 |
+       |        PREFIX64       |                |                 |
+       |======================>|                |                 |
+       | (b) PCP MAP Response  |                |                 |
+       |        PORT_SET       |                |                 |
+       |        PREFIX64:      |                |                 |
+       |     2001:db8:122::/48 |                |                 |
+       |<======================|                |                 |
+       |  (1) SIP INVITE       | (2) SIP INVITE |  (3) SIP INVITE |
+       |======================>|===============>|================>|
+       |   (6) SIP 200 OK      | (5) SIP 200 OK |  (4) SIP 200 OK |
+       |<======================|<===============|<================|
+       |     (7) SIP ACK       |  (8) SIP ACK   |    (9) SIP ACK  |
+       |======================>|===============>|================>|
+       |                       |                |                 |
+       |src port:     dst port:|src port:                dst port:|
+       |port_A           port_B|port_X                      port_B|
+       |<======IPv6 RTP=======>|<============IPv4 RTP============>|
+       |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
+       |src port:     dst port:|src port:                dst port:|
+       |port_A+1       port_B+1|port_X+1                  port_B+1|
+       |                       |                                  |
+
+          Figure 4: Example of IPv6 to IPv4 SIP-Initiated Session
+
+   When the session is initiated from the IPv4-only SIP UA (see Figure
+   5), the IPv6-only SIP UA retrieves a pair of ports to be used for the
+   RTP/RTCP session, the external IPv4 address and the Pref64::/n to
+   build IPv4-converted IPv6 addresses (Steps (a) and (b)).  These two
+   steps could instead be delayed until the INVITE message is received
+   (Step (3)).
+
+   The retrieved IPv4 address and port numbers are used to build the SDP
+   answer in Step (4), while the Pref64::/n is used to construct an IPv6
+   address corresponding to the IPv4 address enclosed in the SDP offer
+   made by the IPv4-only SIP UA (Step (3)).  RTP/RTCP flows are then
+   exchanged between the IPv6-only SIP UA and the IPv4-only UA without
+   requiring any ALG at the NAT64 or any special function at the
+   IPv4-only SIP Proxy Server.
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 12]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   +---------+              +-----+       +------------+     +---------+
+   |IPv6-only|              |NAT64|       |  IPv4 SIP  |     |IPv4-only|
+   | SIP UA  |              |     |       |Proxy Server|     | SIP UA  |
+   +---------+              +-----+       +------------+     +---------+
+       | (a) PCP MAP Request   |                |                 |
+       |        PORT_SET       |                |                 |
+       |        PREFIX64       |                |                 |
+       |======================>|                |                 |
+       | (b) PCP MAP Response  |                |                 |
+       |        PORT_SET       |                |                 |
+       |        PREFIX64:      |                |                 |
+       |     2001:db8:122::/48 |                |                 |
+       |<======================|                |                 |
+       |  (3) SIP INVITE       | (2) SIP INVITE |  (1) SIP INVITE |
+       |<======================|<===============|<================|
+       |   (4) SIP 200 OK      | (5) SIP 200 OK |  (6) SIP 200 OK |
+       |======================>|===============>|================>|
+       |     (9) SIP ACK       |  (8) SIP ACK   |    (7) SIP ACK  |
+       |<======================|<===============|<================|
+       |                       |                |                 |
+       |src port:     dst port:|src port:                dst port:|
+       |port_a           port_b|port_Y                      port_b|
+       |<======IPv6 RTP=======>|<============IPv4 RTP============>|
+       |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
+       |src port:     dst port:|src port:                dst port:|
+       |port_a+1       port_b+1|port_Y+1                  port_b+1|
+       |                       |                                  |
+
+          Figure 5: Example of IPv4 to IPv6 SIP-Initiated Session
+
+5.3.  Mapping of IPv4 Address Ranges to IPv6 Prefixes
+
+   Figure 6 shows an example of a NAT64 configured with two Pref64::/n
+   values; each of these Pref64::/n values is associated with a distinct
+   IPv4 address range:
+
+   o  192.0.2.0/24 is mapped to 2001:db8:122:300::/56.
+
+   o  198.51.100.0/24 is mapped to 2001:db8:122::/48.
+
+   Once the IPv6-only client discovers the IPv4 address of the remote
+   IPv4-only server (i.e., 198.51.100.1), it retrieves two IPv6 prefixes
+   to be used to build an IPv4-converted IPv6 addresses.  This retrieval
+   is achieved using two PREFIX64 options (Step (b)).
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 13]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   Because 198.51.100.1 matches the destination prefix 198.51.100.0/24,
+   the client uses the associated Pref64::/n (i.e., 2001:db8:122::/48)
+   to construct an IPv6 address for that IPv4-only server, and then it
+   initiates a TCP connection (Steps (1) to (6)).
+
+   +---------+                        +-----+             +---------+
+   |IPv6-only|                        |NAT64|             |IPv4-only|
+   | Client  |                        |     |             |  Server |
+   +---------+                        +-----+             +---------+
+       |                                  |               198.51.100.1
+       | (a) PCP MAP Request              |                     |
+       |      PREFIX64                    |                     |
+       |=================================>|                     |
+       | (b) PCP MAP Response             |                     |
+       |PREFIX64{                         |                     |
+       | Pref64::/n =2001:db8:122:300::/56|                     |
+       | IPv4 Prefix=192.0.2.0/24}        |                     |
+       |PREFIX64{                         |                     |
+       | Pref64::/n =2001:db8:122::/48    |                     |
+       | IPv4 Prefix=198.51.100.0/24}     |                     |
+       |<=================================|                     |
+       |    (1) TCP SYN                   |    (2) TCP SYN      |
+       |=================================>|====================>|
+       |   (4) TCP SYN/ACK                |   (3) TCP SYN/ACK   |
+       |<=================================|<====================|
+       |    (5) TCP ACK                   |    (6) TCP ACK      |
+       |=================================>|====================>|
+       |                                  |                     |
+
+   Note: The DNS exchange to retrieve the IPv4 address of
+         the IPv4-only Server is not shown in the figure.
+
+         Figure 6: Mapping of IPv4 Address Ranges to IPv6 Prefixes
+
+   A similar behavior is to be experienced if these Pref64::/n values
+   and associated IPv4 prefix lists are configured to distinct NAT64
+   devices.
+
+6.  IANA Considerations
+
+   The following PCP Option Code has been allocated in the optional-to-
+   process range (the registry is maintained in
+   http://www.iana.org/assignments/pcp-parameters):
+
+      PREFIX64 set to 129 (see Section 4.1)
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 14]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+7.  Security Considerations
+
+   PCP-related security considerations are discussed in [RFC6887].
+
+   As discussed in [RFC6147], if an attacker can manage to change the
+   Pref64::/n used by the DNS64 function, the traffic generated by the
+   host that receives the synthetic reply will be delivered to the
+   altered Pref64.  This can result in either a denial-of-service (DoS)
+   attack, a flooding attack, or a man-in-the-middle (MITM) attack.
+   This attack could be achieved either by altering PCP messages issued
+   by a legitimate PCP server or by using a fake PCP server.
+
+   Means to defend against attackers who can modify packets between the
+   PCP server and the PCP client, or who can inject spoofed packets that
+   appear to come from a legitimate PCP server, SHOULD be enabled.  In
+   some deployments, access control lists (ACLs) can be installed on the
+   PCP client, PCP server, and the network between them, so those ACLs
+   allow only communications from a trusted PCP server to the PCP
+   client.
+
+   PCP server discovery is out of scope for this document.  It is the
+   responsibility of documents about PCP server discovery to elaborate
+   on the security considerations to discover a legitimate PCP server.
+
+   Learning a Pref64::/n via PCP allows using DNSSEC in the presence of
+   NAT64.  As such, NAT64 with DNSSEC and PCP is better than no DNSSEC
+   at all, but it is less safe than DNSSEC without DNS64/NAT64 and PCP.
+   The best mitigation action against Pref64::/n discovery attacks is
+   thus to add IPv6 support in all endpoints and hence reduce the need
+   to perform IPv6 address synthesis.
+
+8.  Acknowledgements
+
+   Many thanks to S. Perreault, R. Tirumaleswar, T. Tsou, D. Wing, J.
+   Zhao, R. Penno, I. van Beijnum, T. Savolainen, S. Savikumar, D.
+   Thaler, T. Lemon, S. Hanna, P. Resnick, R. Sparks, S. Farrell, and W.
+   Cui for their comments and suggestions.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
+              (CIDR): The Internet Address Assignment and Aggregation
+              Plan", BCP 122, RFC 4632, August 2006.
+
+
+
+Boucadair                    Standards Track                   [Page 15]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              April 2011.
+
+   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
+              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
+              2013.
+
+9.2.  Informative References
+
+   [PCP-BITTORRENT]
+              Boucadair, M., Zheng, T., Deng, X., and J. Queiroz,
+              "Behavior of BitTorrent service in PCP-enabled networks
+              with Address Sharing", Work in Progress, May 2012.
+
+   [EXPERIMENTS]
+              Abdesselam, M., Boucadair, M., Hasnaoui, A., and J.
+              Queiroz, "PCP NAT64 Experiments", Work in Progress,
+              September 2012.
+
+   [REF-OBJECT]
+              Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement
+              for Referral", Work in Progress, February 2011.
+
+   [LATCHING] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
+              Traversal (HNT) for Media in Real-Time Communication",
+              Work in Progress, May 2014.
+
+   [PORT-SET] Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou,
+              T., and S. Perreault, "Port Control Protocol (PCP)
+              Extension for Port Set Allocation", Work in Progress,
+              November 2013.
+
+   [WebRTC]   Alvestrand, H., "Overview: Real Time Protocols for Brower-
+              based Applications", Work in Progress, February 2014.
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 16]
+
+RFC 7225                       PCP & NAT64                      May 2014
+
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+              Roberts, "Issues with IP Address Sharing", RFC 6269, June
+              2011.
+
+   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
+              the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
+              7050, November 2013.
+
+   [RFC7051]  Korhonen, J. and T. Savolainen, "Analysis of Solution
+              Proposals for Hosts to Learn NAT64 Prefix", RFC 7051,
+              November 2013.
+
+Author's Address
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   EMail: mohamed.boucadair@orange.com
+
+
+
+
+
+
+
+
+
+
+
+Boucadair                    Standards Track                   [Page 17]
+