Network Working Group F. Baker
Internet-Draft D. Wing
Intended status: Informational Cisco Systems
Expires: July 23, 2012 January 20, 2012
Using PCP to Find an External Address in an NPTv6 Network
draft-baker-pcp-nptv6-search-00
Abstract
This note describes an approach to finding the set of External
Addresses associated with an Internal Address.
Requirements
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2012.
Copyright Notice
Copyright (c) 2012 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
Baker & Wing Expires July 23, 2012 [Page 1]
Internet-Draft Finding external addresses in NPTv6 January 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Using Multicast PCP . . . . . . . . . . . . . . . . . . . . . . 3
2.1. PCP Client: Generating a Request . . . . . . . . . . . . . 3
2.2. PCP Server: Processing a Request . . . . . . . . . . . . . 4
2.3. PCP Client: Processing Responses . . . . . . . . . . . . . 4
2.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. An implementation approach . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Operational Considerations . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Baker & Wing Expires July 23, 2012 [Page 2]
Internet-Draft Finding external addresses in NPTv6 January 2012
1. Introduction
This note uses terminology defined in [I-D.ietf-pcp-base].
Section 5 of [RFC6296] 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.
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.
This note describes an approach to finding the External Addresses
associated with an Internal Address.
2. Using Multicast PCP
Consider a scenario in which the firewall or other system
implementing the NPTv6 Translator also implements a Port Control
Protocol (PCP) [I-D.ietf-pcp-base] 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.
2.1. PCP Client: Generating a Request
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.
Baker & Wing Expires July 23, 2012 [Page 3]
Internet-Draft Finding external addresses in NPTv6 January 2012
2.2. PCP Server: Processing a Request
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 [I-D.ietf-pcp-base]. Then it checks that the MAP
request field's Protocol and Internal Port are both zero; if not, a
MALFORMED_REQUEST error is generated.
If the MAP request contains the THIRD_PARTY option, it MUST contain
an IPv6 address, otherwise it results in a MALFORMED_OPTION error.
Then, depending on the IPv6 prefix of the PCP MAP request (or the
IPv6 prefix of the THIRD_PARTY option, if present):
1. 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).
2. If a translation would occur, the external address is returned in
the Assigned External Address field.
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.
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.
2.3. PCP Client: Processing Responses
Each MAP request sent to the multicast group will result in zero,
one, or more responses (from each NPTv6 listening to that multicast
group).
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.
Renewals should follow the procedure described in Section 10.2.1 of
[I-D.ietf-pcp-base].
Baker & Wing Expires July 23, 2012 [Page 4]
Internet-Draft Finding external addresses in NPTv6 January 2012
2.4. Recovery
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 [I-D.ietf-pcp-base].
3. An implementation approach
A practical implementation of the PCP client in this case would be in
a DNS Server [RFC1034][RFC1035]. 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 Dynamic DNS
[RFC2136][RFC3007] is used with IPv6 Privacy Addresses [RFC4941]),
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.
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.
4. IANA Considerations
This note requests of the IANA the assignment of a set of multicast
addresses as described in Section 2.7 of the IP Version 6 Addressing
Architecture [RFC4291] from the registry [v6mult]. 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.
5. Operational Considerations
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
Baker & Wing Expires July 23, 2012 [Page 5]
Internet-Draft Finding external addresses in NPTv6 January 2012
consider that "site" or "administrative" domain to include the set of
NPTv6 Translators advertising a default route into a specific part of
its network.
6. Security Considerations
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.
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.
In addition, the security considerations in [I-D.ietf-pcp-base] also
apply to this use.
7. Acknowledgements
This note resulted a conversation among the authors, Margaret
Wasserman, Dave Thaler, and Ron Bonica, and from a separate
conversation with Keith Moore.
8. Change Log
Initial Version: January 2012
9. References
Baker & Wing Expires July 23, 2012 [Page 6]
Internet-Draft Finding external addresses in NPTv6 January 2012
9.1. Normative References
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-22 (work in progress), January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[v6mult] IANA, "IPv6 Multicast Address Space Registry",
December 2011, <http://www.iana.org/assignments/
ipv6-multicast-addresses/ipv6-multicast-addresses.xml>.
Baker & Wing Expires July 23, 2012 [Page 7]
Internet-Draft Finding external addresses in NPTv6 January 2012
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Dan Wing
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Baker & Wing Expires July 23, 2012 [Page 8]