idnits 2.17.1 draft-baker-pcp-nptv6-search-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2012) is 4473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-22 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft D. Wing 4 Intended status: Informational Cisco Systems 5 Expires: July 23, 2012 January 20, 2012 7 Using PCP to Find an External Address in an NPTv6 Network 8 draft-baker-pcp-nptv6-search-00 10 Abstract 12 This note describes an approach to finding the set of External 13 Addresses associated with an Internal Address. 15 Requirements 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in [RFC2119]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 23, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Using Multicast PCP . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. PCP Client: Generating a Request . . . . . . . . . . . . . 3 58 2.2. PCP Server: Processing a Request . . . . . . . . . . . . . 4 59 2.3. PCP Client: Processing Responses . . . . . . . . . . . . . 4 60 2.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. An implementation approach . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Operational Considerations . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 This note uses terminology defined in [I-D.ietf-pcp-base]. 76 Section 5 of [RFC6296] points out that there can be issues when an 77 application refers a session initiated by a peer to a third party 78 application running on the same or a different system; it must 79 identify the system the third party application is running on. This 80 is often done by citing an IP address or a DNS name that maps to one 81 or more IP addresses. 83 In a network that uses Network Address Translation or Network Prefix 84 Translation technology, referrals using IP addresses imply that the 85 application must be able to identify both the Internal and External 86 Addresses of the third party. Similarly, when a peer system queries 87 DNS to find an address (either for the initial access or because a 88 referral used a DNS name), DNS must supply it with an address 89 appropriate to its domain. If the two are both in the same network, 90 that would be the Internal Address, and otherwise all External 91 Addresses. 93 This note describes an approach to finding the External Addresses 94 associated with an Internal Address. 96 2. Using Multicast PCP 98 Consider a scenario in which the firewall or other system 99 implementing the NPTv6 Translator also implements a Port Control 100 Protocol (PCP) [I-D.ietf-pcp-base] Server, and that PCP Server joins 101 a multicast group ALL-NPTv6-TRANSLATORS. A PCP Client could send PCP 102 Requests to the multicast group, and get responses from every NPTv6 103 Translator in the domain. 105 2.1. PCP Client: Generating a Request 107 The PCP client sends a MAP Request to that multicast group address, 108 with Internal Port=0 and Protocol=0 (which means 'all ports for all 109 protocols'). To accommodate packet loss, the request SHOULD be 110 transmitted several times with a random jitter between them. It is 111 RECOMMENDED to transmit the MAP Request a total of three times with 112 the first retransmission after 5 seconds plus a random value between 113 0-2.5 seconds, and again at 10 seconds plus a random value between 114 0-5 seconds. 116 2.2. PCP Server: Processing a Request 118 The PCP server embedded in the NPTv6 device first verifies that the 119 PCP message conforms to the requirements of a PCP MAP request as 120 described in [I-D.ietf-pcp-base]. Then it checks that the MAP 121 request field's Protocol and Internal Port are both zero; if not, a 122 MALFORMED_REQUEST error is generated. 124 If the MAP request contains the THIRD_PARTY option, it MUST contain 125 an IPv6 address, otherwise it results in a MALFORMED_OPTION error. 127 Then, depending on the IPv6 prefix of the PCP MAP request (or the 128 IPv6 prefix of the THIRD_PARTY option, if present): 130 1. If no translation applies to that IPv6 address (i.e., the address 131 is not within a prefix that is translated) the Assigned External 132 Address of the MAP response is set to the same as the IP address 133 from the IP header of the PCP request (unless THIRD_PARTY was 134 used, in which case it is set to the IP address of the 135 THIRD_PARTY option). 137 2. If a translation would occur, the external address is returned in 138 the Assigned External Address field. 140 If the NPTv6 device itself is multihomed (i.e., it contains multiple 141 NPTv6 translation functions), a separate MAP Response is sent for 142 each NPTv6 instance -- as if they were separate devices. These MAY 143 be sent from the same unicast source address. 145 It is RECOMMENDED that the Assigned Lifetime of the MAP response be 146 the remaining lifetime of the ISP-assigned address. In this way, PCP 147 clients receive timely updates to the IPv6 address assigned by the 148 ISP. 150 2.3. PCP Client: Processing Responses 152 Each MAP request sent to the multicast group will result in zero, 153 one, or more responses (from each NPTv6 listening to that multicast 154 group). 156 If the network contains multiple NPTv6 instances, multiple MAP 157 responses will normally be received. If multiple responses are 158 received, the shortest PCP Assigned Lifetime should be used when 159 sending renewal multicast PCP requests. 161 Renewals should follow the procedure described in Section 10.2.1 of 162 [I-D.ietf-pcp-base]. 164 2.4. Recovery 166 An NPTv6 device may join or leave a network unexpectedly (e.g., 167 device failure, link failure, or link recovery). To accommodate 168 these situations, the NPTv6 devices SHOULD implement PCP Rapid 169 Recovery, as described in Section 13 of [I-D.ietf-pcp-base]. 171 3. An implementation approach 173 A practical implementation of the PCP client in this case would be in 174 a DNS Server [RFC1034][RFC1035]. Whenever it learns of a mapping 175 between a name and an Internal Address (which might happen only at 176 startup in a static system, or might happen frequently if Dynamic DNS 177 [RFC2136][RFC3007] is used with IPv6 Privacy Addresses [RFC4941]), 178 the DNS Server queries ALL-NPTv6-TRANSLATORS for the list of relevant 179 addresses to create AAAA Resource Records for. It may get no 180 response (although if there are no such translators one would hope 181 for an ICMP Host Unreachable response rather than letting it time 182 out), one response, or many. It always makes a Resource Record for 183 the Internal Address; it also makes Resource Records for any External 184 Addresses reported. Such translations come with lifetimes; the DNS 185 Server is responsible to re-request as lifetimes expire, and to not 186 grant longer Resource Record lifetimes than it has address lifetimes. 188 Any system needing to know its own External Addresses or those of 189 another party could then obtain them by resolving the relevant DNS 190 name, or could follow the same process. 192 4. IANA Considerations 194 This note requests of the IANA the assignment of a set of multicast 195 addresses as described in Section 2.7 of the IP Version 6 Addressing 196 Architecture [RFC4291] from the registry [v6mult]. This set of 197 addresses is referred to as "ALL-NPTv6-TRANSLATORS". One address 198 should be assigned for each of the following scopes: Link-Local, 199 Admin-Local, Site-Local, and Organization-Local. 201 5. Operational Considerations 203 This document defines a set of multicast addresses in several scopes. 204 Operationally, the choice of which scope is appropriate is made by 205 the administration. A reasonable default value in system 206 configurations might be Organization-Local (e.g., all NPTv6 207 Translators operated by the organization). However, a large 208 organization might well choose Site-Local or Admin-Local, and 209 consider that "site" or "administrative" domain to include the set of 210 NPTv6 Translators advertising a default route into a specific part of 211 its network. 213 6. Security Considerations 215 The principal security threat in this algorithm is a security threat 216 inherent to IP multicast routing and any application that runs on it. 217 A rogue system can join a multicast group, meaning it that it sees 218 traffic sent to the multicast group that it was presumably not 219 intended to see, and may originate responses that are not correct or 220 infer information. Such a rogue system also in effect pulls traffic 221 toward it, which may not have been planned for in capacity planning. 222 In this scenario, the rogue system has the opportunity to learn the 223 addresses of every system that has such a translation, and has the 224 capability of adding an incorrect External Address to any list of 225 External Addresses. This presents both privacy and security issues. 227 The obvious mitigation is authentication and authorization of 228 responses returned; requesters should verify that responses are 229 coming from systems that the administration thinks are legitimately 230 NPTv6 Translators. PCP does not define an authentication model, and 231 does not define the use of TLS/DTLS or others. Hence, this likely 232 implies the use of IPSec, or at least a list of the addresses of 233 authorized NPTv6 translators in the network, with administration- 234 specific responses to rogue equipment such as ignoring such responses 235 or some form of remediation. If the multicast routing technology 236 supports it, refusing such rogue "joins" would be a good idea. 238 In addition, the security considerations in [I-D.ietf-pcp-base] also 239 apply to this use. 241 7. Acknowledgements 243 This note resulted a conversation among the authors, Margaret 244 Wasserman, Dave Thaler, and Ron Bonica, and from a separate 245 conversation with Keith Moore. 247 8. Change Log 249 Initial Version: January 2012 251 9. References 252 9.1. Normative References 254 [I-D.ietf-pcp-base] 255 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 256 Selkirk, "Port Control Protocol (PCP)", 257 draft-ietf-pcp-base-22 (work in progress), January 2012. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 263 Architecture", RFC 4291, February 2006. 265 9.2. Informative References 267 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 268 STD 13, RFC 1034, November 1987. 270 [RFC1035] Mockapetris, P., "Domain names - implementation and 271 specification", STD 13, RFC 1035, November 1987. 273 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 274 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 275 RFC 2136, April 1997. 277 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 278 (IPv6) Specification", RFC 2460, December 1998. 280 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 281 Update", RFC 3007, November 2000. 283 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 284 Extensions for Stateless Address Autoconfiguration in 285 IPv6", RFC 4941, September 2007. 287 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 288 Translation", RFC 6296, June 2011. 290 [v6mult] IANA, "IPv6 Multicast Address Space Registry", 291 December 2011, . 294 Authors' Addresses 296 Fred Baker 297 Cisco Systems 298 Santa Barbara, California 93117 299 USA 301 Email: fred@cisco.com 303 Dan Wing 304 Cisco Systems 305 170 West Tasman Drive 306 San Jose, California 95134 307 USA 309 Email: dwing@cisco.com