One document matched: draft-ietf-pcp-nat64-prefix64-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="std" docName="draft-ietf-pcp-nat64-prefix64-01"
ipr="trust200902" updates="">
<front>
<title abbrev="PCP & NAT64">Learn NAT64 PREFIX64s using PCP</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date day="22" month="May" year="2013" />
<workgroup>PCP Working Group</workgroup>
<keyword>Referrals</keyword>
<abstract>
<t>This document defines a new PCP extension to learn the IPv6
prefix(es) used by a PCP-controlled NAT64 device to build IPv4-embedded
IPv6 addresses. This extension is needed for successful communications
when IPv4 addresses are used in referrals.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines a new PCP extension <xref
target="RFC6887"></xref> to inform PCP clients about the Pref64::/n
<xref target="RFC6052"></xref> used by a PCP-controlled NAT64 device
<xref target="RFC6146"></xref>. It does so by defining a new PREFIX64
option.</t>
<t>This extension is required to help establishing communications
between IPv6-only hosts and remote IPv4-only hosts.</t>
<t>Some illustration examples are provided in <xref
target="examples"></xref>. Detailed experiment results are available at
<xref target="I-D.boucadair-pcp-nat64-experiments"></xref>.</t>
<t>The use of this PCP extension for NAT64 load balancing purposes
(<xref target="I-D.zhang-behave-nat64-load-balancing"></xref>) is out of
scope. </t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="problem" title="Problem Statement">
<t></t>
<section title="Issues">
<t>This document proposes a deterministic solution to solve the
following issues:<list style="symbols">
<t>Learn the Pref64::/n used by an upstream NAT64 function. This
is needed to help:<list style="symbols">
<t>distinguishing between IPv4-converted IPv6 addresses and
native IPv6 addresses.</t>
<t>implementing IPv6 address synthesis for applications not
relying on DNS.</t>
</list></t>
<t>Avoid stale Pref64::/n.</t>
<t>Discover multiple Pref64::/n when multiple prefixes in a
network.</t>
<t>Use DNSSEC in the presence of NAT64.</t>
</list></t>
<t><xref target="usecase"></xref> lists some applications which
encounter the issues listed above.</t>
</section>
<section anchor="usecase" title="Use Cases">
<t></t>
<section title="AAAA Synthesis by Stub-resolver">
<t>The extension defined in this document can be used for hosts with
DNS64 capability <xref target="RFC6147"></xref>, added to the host's
stub-resolver.</t>
<t>The stub resolver on the host will try to obtain (native) AAAA
records and if it they are not found, the DNS64 function on the host
will query for A records and then synthesizes AAAA records. Using
the PREFIX64 PCP extension, the host's stub-resolver can learn the
prefix used for IPv6/IPv4 translator and synthesize AAAA records
accordingly.</t>
<t>Learning the Pref64::/n used to construct IPv4-converted IPv6
addresses <xref target="RFC6052"></xref> allows to make use of
DNSSEC.</t>
</section>
<section title="Applications Referrals">
<t>As discussed in <xref
target="I-D.carpenter-behave-referral-object"></xref>, a frequently
occurring situation is that one entity A connected to the Internet
(or to some private 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.</t>
<t>In the particular context of NAT64 <xref
target="RFC6146"></xref>, 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
applications is provided below:</t>
<t><list style="symbols">
<t>BitTorrent is a distributed file sharing infrastructure which
is based on P2P techniques for exchanging files between
connected users. In order to download a given file, a BitTorrent
client needs to obtain the corresponding torrent file. Then, it
connects to the tracker to retrieve a list of lechers (clients
which are currently downloading the file but do not yet detain
all the portions of the file) and seeders (clients which detain
all the 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, some encountered issues
are solved if PCP is enabled (see <xref
target="I-D.boucadair-pcp-bittorrent"></xref>). Nevertheless, an
IPv6-only client can not connect to a remote IPv4-only machine
even if base PCP is enabled. An extension is needed to solve
this concern.</t>
<t>In SIP environments <xref target="RFC3261"></xref>, the SDP
part of exchanged SIP messages includes required information for
establishment of RTP sessions (particularly IP address and port
number). When a NAT64 is involved in the path, an IPv6-only SIP
UA (User Agent) which receives an SDP offer/answer containing an
IPv4 address, cannot send media streams to the remote
endpoint.</t>
<t>An IPv6-only WebRTC (Web Real-Time communication, <xref
target="I-D.ietf-rtcweb-overview"></xref>) can not make use of
an IPv4 address received in referrals to establish a successful
session with a remote IPv4-only WebRTC agent.</t>
</list></t>
<t></t>
</section>
</section>
</section>
<section anchor="PREFIX64" title="PREFIX64 Option">
<t></t>
<section title="Format">
<t>The format of the PREFIX64 option is depicted in <xref
target="option"></xref>. This option follows the guidelines specified
in Section 7.3 of <xref target="RFC6887"></xref>.</t>
<t><figure align="center" anchor="option" title="Prefix64 PCP Option">
<artwork><![CDATA[ 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 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix64 (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>The description of the fields is as follows:</t>
<t><list style="symbols">
<t>Option Code: To be assigned by IANA.</t>
<t>Option Length: Indicates in octets the length of the
Pref64::/n. Allowed values are 4, 5, 6, 7, 8, or 12 <xref
target="RFC6052"></xref>.</t>
<t>Prefix64: This field identifies the IPv6 unicast prefix to be
used for constructing an IPv4-embedded IPv6 address from an IPv4
address. The address synthesize MUST follow the guidelines
documented in <xref target="RFC6052"></xref>.</t>
</list><figure>
<artwork><![CDATA[ Option Name: PREFIX64
Number: <to be assigned in the optional-to-process range>
Purpose: Learn the prefix used by the NAT64 to build
IPv4-embedded IPv6 addresses. This is used by a host
for local address synthesis (e.g., when 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
maximum PCP message size for a response.]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Behavior">
<t>The PCP client includes a PREFIX64 option in a MAP or ANNOUNCE
request to learn the IPv6 prefix used by an upstream PCP-controlled
NAT64 device. When enclosed in a PCP request, 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 <xref
target="RFC6887"></xref>.</t>
<t>The PCP server controlling a NAT64 SHOULD be configured to return
to requesting PCP clients the value of the Pref64::/n used to build
IPv4-embedded IPv6 addresses. When enabled, the PREFIX64 option
conveys the value of Pref64::/n.</t>
<t>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.</t>
<t>When multiple prefixes are configured in a network, the PCP server
MAY be configured to return multiple PREFIX64 options in the same
message to the PCP client. The PCP server includes in the first
PREFIX64 option, which appears in the PCP message it sends to the PCP
client, the prefix to perform local IPv6 address synthesis <xref
target="RFC6052"></xref>. Remaining PREFIX64 options convey other
Pref64::/n configured in the network. Returning these prefixes allows
an end host to avoid any NAT64 deployed in the network. </t>
<t>The host embedding the PCP client uses the prefix included in the
first PREFIX64 option for local address synthesize. Remaining prefixes
are used by the host to avoid any NAT64 deployed in the network. How
the content of the PREFIX64 option(s) is passed to the OS is
implementation-specific.</t>
<t>The PCP client MUST be prepared to receive multiple Pref64::/n
(e.g., if several PCP servers are deployed; each of them is configured
with a distinct Pref64::/n). The PCP client SHOULD associate each
received Pref64::/n with the PCP server from which the Pref64::/n
information was retrieved. If the PCP client fails to contact a given
PCP server, the PCP client SHOULD clear the prefix(es) it learned from
that PCP server.</t>
<t>If a distinct Pref64::/n is configured to the PCP-controlled NAT64
device, the PCP server SHOULD issue an unsolicited PCP message to
inform the PCP client about the new Pref64::/n. Upon receipt of this
message, the PCP client replaces the old prefix received from the same
PCP server with the new Pref64::/n included in the PREFIX64 option.
</t>
</section>
</section>
<section anchor="examples" title="Flow Examples">
<t>This section provides a non-normative description of use cases
relying on the PREFIX64 option.</t>
<section title="TCP Session Initiated from an IPv6-only Host">
<t>The usage shown in <xref target="ex5"></xref> depicts a typical
usage of the PREFIX64 option when a DNS64 capability is embedded in
the host.</t>
<t>In the example shown in <xref target="ex5"></xref>, once the
IPv6-only client discovered the IPv4 address of the remote IPv4-only
server, it retrieves the Pref64::/n (i.e., 2001:db8:122:300::/56) to
be used to build an IPv4-embedded IPv6 address for that server. This
is achieved using the PREFIX64 option (Steps (a) and (b)). The client
uses 2001:db8:122:300::/56 to construct an IPv6 address and then
initiates a TCP connection (Steps (1) to (4)).</t>
<t><figure align="center" anchor="ex5"
title="Example of TCP session initiated from an IPv6-only host">
<artwork><![CDATA[
+---------+ +-----+ +---------+
|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 |
|======================>|====================>|
| | |
]]></artwork>
</figure></t>
</section>
<section title="SIP Flow Example">
<t><xref target="ex2"></xref> shows an example of the use of the
option defined in <xref target="PREFIX64"></xref> 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 nor any particular function at the IPv4-only SIP
Proxy Server (e.g., Hosted NAT traversal), the PORT_SET option <xref
target="I-D.ietf-pcp-port-set"></xref> is used in addition to the
PREFIX64 option.</t>
<t>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 which 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 are then returned by the PCP server to the
requesting PCP client together with a Pref64::/n (i.e.,
2001:db8:122::/48).</t>
<t>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 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., IPv4-only SIP UA) (Steps (1) to (3)). </t>
<t>The remote IPv4-only SIP UA accepts the offer and sends back its
SDP answer in a "200 OK" message which is relayed by the SIP Proxy
Server and NAT64 until being delivered to IPv6-only SIP UA (Steps (4)
to (6)). </t>
<t>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). </t>
<t>IPv6-only SIP UA and IPv4-only SIP UA are then able to exchange
RTP/RTCP flows without requiring any ALG at the NAT64 nor any
particular function at the IPv4-only SIP Proxy Server.</t>
<t><figure align="center" anchor="ex2"
title="Example of IPv6 to IPv4 SIP initiated Session">
<artwork><![CDATA[
+---------+ +-----+ +------------+ +---------+
|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|
| | |
]]></artwork>
</figure></t>
<t>When the session is initiated from the IPv4-only SIP UA (see <xref
target="ex3"></xref>), the IPv6-only SIP UA retrieves a pair of ports
to be used for RTP/RTCP session, the external IPv4 address and the
Pref64::/n to build IPv4-embedded IPv6 addresses (Steps (a) and (b)).
These two steps can be delayed until receiving the INVITE message
(Step 3).</t>
<t>The retrieved IPv4 address and port numbers are used to build the
SDP answer in Step (4) while Pref64::/n is used to construct a
corresponding IPv6 address of the IPv4 address enclosed in the SDP
offer made by the IPv4-only SIP UA (Step 3). RTP/RTCP flows are
exchanged between an IPv6-only SIP UA and an IPv4-only UA without
requiring any ALG at the NAT64 nor any function at the IPv4-only SIP
Proxy Server.</t>
<t><figure align="center" anchor="ex3"
title="Example of IPv4 to IPv6 SIP initiated Session">
<artwork><![CDATA[
+---------+ +-----+ +------------+ +---------+
|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|
| | |
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The following PCP Option Code is to be allocated in the
optional-to-process range (the registry is maintained in
http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml#option-rules):<list
style="empty">
<t>PREFIX64</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>PCP-related security considerations are discussed in <xref
target="RFC6887"></xref>.</t>
<t>As discussed in <xref target="RFC6147"></xref>, an attacker can
manage to change the Pref64::/n used by the DNS64, 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 an eavesdropping attack. This attack can
be achieved by altering PCP messages issued by a legitimate PCP server
or a fake PCP server is used.</t>
<t>Means to defend against attackers who can modify 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. For example,
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.</t>
<t>PCP server discovery is out of scope of this document. It is the
responsibility of PCP server discovery document(s) to elaborate on the
security considerations to discover a legitimate PCP server.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to S. Perreault , R. Tirumaleswar, T. Tsou, D. Wing, J.
Zhao, R. Penno and I. Van Beijnum for the comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.6147'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.3261'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-pcp-port-set'?>
<?rfc include='reference.I-D.boucadair-pcp-nat64-experiments'?>
<?rfc include='reference.I-D.carpenter-behave-referral-object'?>
<?rfc include='reference.I-D.boucadair-pcp-bittorrent'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.zhang-behave-nat64-load-balancing'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:39 |