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 28, 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 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
• 2. Using Multicast PCP
• 2.1. PCP Client: Generating a Request
• 2.2. PCP Server: Processing a Request
• 2.3. PCP Client: Processing Responses
• 2.4. Recovery
• 3. An implementation approach
• 4. IANA Considerations
• 5. Operational Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. Change Log
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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.

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].

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 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

9.1. Normative References

9.2. Informative References

Authors' Addresses