One document matched: draft-baker-pcp-nptv6-search-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-pcp-nptv6-search-00"
ipr="trust200902">
<front>
<title abbrev="Finding external addresses in NPTv6">Using PCP to Find an
External Address in an NPTv6 Network</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Internet Engineering Task Force</area>
<workgroup></workgroup>
<abstract>
<t>This note describes an approach to finding the set of External
Addresses associated with an Internal Address.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements">
<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>
</note>
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This note uses terminology defined in <xref
target="I-D.ietf-pcp-base"></xref>.</t>
<t>Section 5 of <xref target="RFC6296"></xref> points out that there can
be issues when an application refers a session initiated by a peer to a
third party application running on the same or a different system; it
must identify the system the third party application is running on. This
is often done by citing an IP address or a DNS name that maps to one or
more IP addresses.</t>
<t>In a network that uses Network Address Translation or Network Prefix
Translation technology, referrals using IP addresses imply that the
application must be able to identify both the Internal and External
Addresses of the third party. Similarly, when a peer system queries DNS
to find an address (either for the initial access or because a referral
used a DNS name), DNS must supply it with an address appropriate to its
domain. If the two are both in the same network, that would be the
Internal Address, and otherwise all External Addresses.</t>
<t>This note describes an approach to finding the External Addresses
associated with an Internal Address.</t>
</section>
<section anchor="pcp-query" title="Using Multicast PCP">
<t>Consider a scenario in which the firewall or other system
implementing the NPTv6 Translator also implements a <xref
target="I-D.ietf-pcp-base">Port Control Protocol (PCP)</xref> Server,
and that PCP Server joins a multicast group ALL-NPTv6-TRANSLATORS. A PCP
Client could send PCP Requests to the multicast group, and get responses
from every NPTv6 Translator in the domain.</t>
<section title="PCP Client: Generating a Request">
<t>The PCP client sends a MAP Request to that multicast group address,
with Internal Port=0 and Protocol=0 (which means 'all ports for all
protocols'). To accommodate packet loss, the request SHOULD be
transmitted several times with a random jitter between them. It is
RECOMMENDED to transmit the MAP Request a total of three times with
the first retransmission after 5 seconds plus a random value between
0-2.5 seconds, and again at 10 seconds plus a random value between 0-5
seconds.</t>
</section>
<section title="PCP Server: Processing a Request">
<t>The PCP server embedded in the NPTv6 device first verifies that the
PCP message conforms to the requirements of a PCP MAP request as
described in <xref target="I-D.ietf-pcp-base"></xref>. Then it checks
that the MAP request field's Protocol and Internal Port are both zero;
if not, a MALFORMED_REQUEST error is generated.</t>
<t>If the MAP request contains the THIRD_PARTY option, it MUST contain
an IPv6 address, otherwise it results in a MALFORMED_OPTION error.</t>
<t>Then, depending on the IPv6 prefix of the PCP MAP request (or the
IPv6 prefix of the THIRD_PARTY option, if present):</t>
<t><list style="numbers">
<t>If no translation applies to that IPv6 address (i.e., the
address is not within a prefix that is translated) the Assigned
External Address of the MAP response is set to the same as the IP
address from the IP header of the PCP request (unless THIRD_PARTY
was used, in which case it is set to the IP address of the
THIRD_PARTY option).</t>
<t>If a translation would occur, the external address is returned
in the Assigned External Address field.</t>
</list></t>
<t>If the NPTv6 device itself is multihomed (i.e., it contains
multiple NPTv6 translation functions), a separate MAP Response is sent
for each NPTv6 instance -- as if they were separate devices. These MAY
be sent from the same unicast source address.</t>
<t>It is RECOMMENDED that the Assigned Lifetime of the MAP response be
the remaining lifetime of the ISP-assigned address. In this way, PCP
clients receive timely updates to the IPv6 address assigned by the
ISP.</t>
</section>
<section title="PCP Client: Processing Responses">
<t>Each MAP request sent to the multicast group will result in zero,
one, or more responses (from each NPTv6 listening to that multicast
group).</t>
<t>If the network contains multiple NPTv6 instances, multiple MAP
responses will normally be received. If multiple responses are
received, the shortest PCP Assigned Lifetime should be used when
sending renewal multicast PCP requests.</t>
<t>Renewals should follow the procedure described in Section 10.2.1 of
<xref target="I-D.ietf-pcp-base"></xref>.</t>
</section>
<section anchor="recovery" title="Recovery">
<t>An NPTv6 device may join or leave a network unexpectedly (e.g.,
device failure, link failure, or link recovery). To accommodate these
situations, the NPTv6 devices SHOULD implement PCP Rapid Recovery, as
described in Section 13 of <xref
target="I-D.ietf-pcp-base"></xref>.</t>
</section>
</section>
<section anchor="dns" title="An implementation approach">
<t>A practical implementation of the PCP client in this case would be in
a <xref target="RFC1034">DNS Server</xref><xref
target="RFC1035"></xref>. Whenever it learns of a mapping between a name
and an Internal Address (which might happen only at startup in a static
system, or might happen frequently if <xref target="RFC2136">Dynamic
DNS</xref><xref target="RFC3007"></xref> is used with <xref
target="RFC4941">IPv6 Privacy Addresses</xref>), the DNS Server queries
ALL-NPTv6-TRANSLATORS for the list of relevant addresses to create AAAA
Resource Records for. It may get no response (although if there are no
such translators one would hope for an ICMP Host Unreachable response
rather than letting it time out), one response, or many. It always makes
a Resource Record for the Internal Address; it also makes Resource
Records for any External Addresses reported. Such translations come with
lifetimes; the DNS Server is responsible to re-request as lifetimes
expire, and to not grant longer Resource Record lifetimes than it has
address lifetimes.</t>
<t>Any system needing to know its own External Addresses or those of
another party could then obtain them by resolving the relevant DNS name,
or could follow the same process.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This note requests of the IANA the assignment of a set of multicast
addresses as described in Section 2.7 of the <xref target="RFC4291">IP
Version 6 Addressing Architecture</xref> from the registry <xref
target="v6mult"></xref>. This set of addresses is referred to as
"ALL-NPTv6-TRANSLATORS". One address should be assigned for each of the
following scopes: Link-Local, Admin-Local, Site-Local, and
Organization-Local.</t>
</section>
<section title="Operational Considerations">
<t>This document defines a set of multicast addresses in several scopes.
Operationally, the choice of which scope is appropriate is made by the
administration. A reasonable default value in system configurations
might be Organization-Local (e.g., all NPTv6 Translators operated by the
organization). However, a large organization might well choose
Site-Local or Admin-Local, and consider that "site" or "administrative"
domain to include the set of NPTv6 Translators advertising a default
route into a specific part of its network.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The principal security threat in this algorithm is a security threat
inherent to IP multicast routing and any application that runs on it. A
rogue system can join a multicast group, meaning it that it sees traffic
sent to the multicast group that it was presumably not intended to see,
and may originate responses that are not correct or infer information.
Such a rogue system also in effect pulls traffic toward it, which may
not have been planned for in capacity planning. In this scenario, the
rogue system has the opportunity to learn the addresses of every system
that has such a translation, and has the capability of adding an
incorrect External Address to any list of External Addresses. This
presents both privacy and security issues.</t>
<t>The obvious mitigation is authentication and authorization of
responses returned; requesters should verify that responses are coming
from systems that the administration thinks are legitimately NPTv6
Translators. PCP does not define an authentication model, and does not
define the use of TLS/DTLS or others. Hence, this likely implies the use
of IPSec, or at least a list of the addresses of authorized NPTv6
translators in the network, with administration-specific responses to
rogue equipment such as ignoring such responses or some form of
remediation. If the multicast routing technology supports it, refusing
such rogue "joins" would be a good idea.</t>
<t>In addition, the security considerations in <xref
target="I-D.ietf-pcp-base"></xref> also apply to this use.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note resulted a conversation among the authors, Margaret
Wasserman, Dave Thaler, and Ron Bonica, and from a separate
conversation with Keith Moore.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">January 2012</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-pcp-base" ?>
<?rfc include="reference.RFC.4291" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.2136" ?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.3007" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.6296" ?>
<reference anchor="v6mult"
target="http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml">
<front>
<title>IPv6 Multicast Address Space Registry</title>
<author fullname="IANA" surname="IANA">
<organization>IANA</organization>
</author>
<date month="December" year="2011" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:23 |