One document matched: draft-ietf-pcp-nat64-prefix64-03.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-03"
ipr="trust200902" updates="">
<front>
<title abbrev="PCP & NAT64">Learning 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="05" month="June" 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-converted
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 and
suffix <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 a deterministic solution to help establish
communications between IPv6-only hosts and remote IPv4-only hosts.
Unlike <xref target="I-D.ietf-behave-nat64-discovery-heuristic"></xref>,
this extension solves all the issues identified in <xref
target="I-D.ietf-behave-nat64-learn-analysis"></xref>. </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 anchor="issues" 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>distinguish between IPv4-converted IPv6 addresses <xref
target="RFC6052"></xref> and native IPv6 addresses.</t>
<t>implement IPv6 address synthesis for applications not
relying on DNS (where DNS64 <xref target="RFC6147"></xref>
would provide the synthesis).</t>
</list></t>
<t>Avoid stale Pref64::/n.</t>
<t>Discover multiple Pref64::/n when multiple prefixes exist in a
network.</t>
<t>Support destination-dependent Pref64::/n.</t>
<t>Use DNSSEC (<xref target="RFC4033"></xref>, <xref
target="RFC4034"></xref>, <xref target="RFC4035"></xref>) in the
presence of NAT64.</t>
<t>Discover the suffix used by an NAT64 function when non-null
suffixes are in use (e.g., checksum neutral suffix).</t>
<t>Support destination-based Pref64::/n (Section 5.1 of <xref
target="I-D.ietf-behave-nat64-discovery-heuristic"></xref>).</t>
<t>Associate a Pref64::/n with a given NAT64 when distinct
prefixes are configured for each NAT64 enabled in a network.</t>
</list></t>
<t>A more elaborated discussion can be found at <xref
target="I-D.ietf-behave-nat64-learn-analysis"></xref>.</t>
</section>
<section anchor="usecase" title="Use Cases">
<t>This section provides some use cases to illustrate the problem
space. More details can be found at Section 4 of <xref
target="I-D.ietf-behave-nat64-learn-analysis"></xref>.</t>
<section title="AAAA Synthesis by the DNS 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 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 translation and synthesize AAAA records
accordingly.</t>
<t>Learning the Pref64::/n used to construct IPv4-converted IPv6
addresses allows the use of DNSSEC.</t>
</section>
<section title="Application 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 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.</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
such applications is provided below:</t>
<t><list style="symbols">
<t>In SIP environments <xref target="RFC3261"></xref>, the SDP
part (<xref target="RFC4566"></xref>) 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.</t>
<t>An IPv6-only WebRTC (Web Real-Time Communication, <xref
target="I-D.ietf-rtcweb-overview"></xref>) agent cannot make use
of an IPv4 address received in referrals to establish a
successful session with a remote IPv4-only WebRTC agent.</t>
<t>BitTorrent is a distributed file sharing infrastructure that
is based on 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 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 <xref
target="RFC6269"></xref>), some encountered issues are solved if
PCP is enabled (see <xref
target="I-D.boucadair-pcp-bittorrent"></xref>). Nevertheless, an
IPv6-only client cannot connect to a remote IPv4-only machine
even if the base PCP protocol is used.</t>
</list></t>
<t>Learning the Pref64::/n solves the issues listed above.</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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pref64 Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: Pref64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Suffix (Variable) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) |
: IPv4 Prefix List (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 enclosed
data.</t>
<t>Pref64 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-converted IPv6 address from an IPv4
address as specified in Section 2.2 of <xref
target="RFC6052"></xref>. 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 <xref
target="RFC6052"></xref>.</t>
<t>Suffix: The length of this field is (12 - Pref64 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 <xref target="RFC6052"></xref>. No
suffix is included if a /96 Prefix64 is conveyed in the
option.</t>
<t>IPv4 Prefix List: This is an optional field. The format of the
IPv4 Prefix List field is shown in <xref
target="ipv4dest"></xref>. This field may be included by a PCP
server to solve the destination-dependent Pref64::/n discovery
problem discussed in Section 5.1 of <xref
target="I-D.ietf-behave-nat64-discovery-heuristic"></xref>.<list
style="symbols">
<t>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.</t>
<t>An IPv4 prefix is represented as "IPv4 Address/IPv4 Prefix
Length" <xref target="RFC4632"></xref>. 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 <xref
target="RFC4632"></xref>. </t>
</list></t>
</list></t>
<t><figure align="center" anchor="ipv4dest"
title="Format of IPv4 Prefix List field">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Count | IPv4 Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix Length | IPv4 Address (32 bits)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t></t>
<t><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-converted IPv6 addresses. This is used by a host
is for local address synthesis (e.g., when an IPv4 address
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.]]></artwork>
</figure></t>
</section>
<section title="Behavior">
<t>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 <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 and suffix used
to build IPv4-converted IPv6 addresses. When enabled, the PREFIX64
option conveys the value of Pref64::/n and configured suffix. If no
suffix is explicitly configured to the PCP server, the null suffix is
used as default value (see Section 2.2 of <xref
target="RFC6052"></xref>).</t>
<t>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.</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>The PCP server MAY be configured with a list of destination IPv4
prefixes associated with each Pref64::/n. This list is then included
by the PCP server in a PREFIX64 option sent to PCP clients. </t>
<t>If the PCP client receives a PREFIX64 option that includes an
invalid IPv4 prefix, the PCP client ignores that IPv4 prefix. Any
other valid IPv4 prefix, IPv6 prefix and suffix are not ignored by the
PCP client. </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:<list style="symbols">
<t>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 <xref
target="RFC6052"></xref>. Remaining PREFIX64 options convey any
other Pref64::/n values configured. Returning these prefixes
allows an end host to identify them as translated addresses, and
instead prefer IPv4 or an alternative network interface in order
to avoid any NAT64 deployed in the network. The PCP server is
supposed to be able 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-wise IPv6 prefix list (i.e., the same list is
return for any PCP client).</t>
<t>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. Remaining PREFIX64 options
convey any other Pref64::/n values configured. </t>
</list></t>
<t>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. Remaining prefixes 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. </t>
<t>The PCP client MUST be prepared to receive multiple prefix(es)
(e.g., if several PCP servers are deployed and each of them is
configured with a distinct Pref64::/n). The PCP client SHOULD
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.</t>
<t>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. Upon receipt of this 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.</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 discovers 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-converted IPv6 address for that server. This
retrieval is achieved using the PREFIX64 option (Steps (a) and (b)).
The client then 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 a 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 <xref
target="I-D.ietf-mmusic-latching"></xref>), 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 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 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 the IPv6-only SIP UA (Steps
(4) to (6)).</t>
<t>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).</t>
<t>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 nor any special
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 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).</t>
<t>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 a
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 nor any special 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>, 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 an eavesdropping
attack. This attack could be achieved either by altering PCP messages
issued by a legitimate PCP server or by using a fake PCP server.</t>
<t>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. 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>
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to S. Perreault , R. Tirumaleswar, T. Tsou, D. Wing, J.
Zhao, R. Penno, I. Van Beijnum, T. Savolainen, S. Savikumar, and D.
Thaler 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.4632'?>
</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.ietf-behave-nat64-discovery-heuristic'?>
<?rfc include='reference.I-D.ietf-behave-nat64-learn-analysis'?>
<?rfc include='reference.I-D.zhang-behave-nat64-load-balancing'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.I-D.ietf-mmusic-latching'?>
<?rfc include='reference.RFC.4033'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.4035'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.4566'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:16 |