idnits 2.17.1 draft-durand-v6ops-natpt-dns-alg-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 361 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([NAT-PT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 139 has weird spacing: '...on with node ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2003) is 7576 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 13, but not defined ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Alain Durand 2 INTERNET-DRAFT SUN Microsystems 3 January 29, 2003 4 Expires July 30, 2003 6 Issues with NAT-PT DNS ALG in RFC2766 7 9 Status of this memo 11 This memo provides information to the Internet community. It does 12 not specify an Internet standard of any kind. This memo is in full 13 conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 15 The list of current Internet-Drafts can be accessed at 16 http://www.ietf.org/ietf/1id-abstracts.txt 17 The list of Internet-Draft Shadow Directories can be accessed at 18 http://www.ietf.org/shadow.html. 20 Abstract 22 Recent discussions on the need to translate or not between IPv4 and 23 IPv6 have brought a better understanding on the impact of tools like 24 NAT-PT [NAT-PT]. Several problems have been identified around the 25 DNS ALG functionality. An alternative solution that does not require 26 this DNS ALG for connections initiated by the IPv6 side has been 27 proposed. This memo aims at analyzing the pros and cons of both 28 solutions in that case. Connections initiated by the IPv4 side would 29 always require the help of a DNS-ALG and thus are not covered by this 30 memo. 32 1. Introduction: non DNS ALG solution 34 Note: This section does not provide a complete description of a non 35 DNS ALG solution for NAT-PT, but provide a quick overview of such a 36 solution to understand better the discussions of the next sections. 38 For outgoing connections, DNS-ALG is there in NAT-PT only to provide 39 a local prefix for the address mapping. If a well known prefix were 40 defined, there would be no need for DNS ALG. However, for incoming 41 connection, there is no other way than relying on a DNS ALG. 43 For outgoing connections, the consequences of this change would be 44 that end-nodes willing to use the translator would now have the 45 responsibility to do so, it would not happen automatically, and such 46 IPv6-only end nodes would have to be specifically programmed to do 47 so. 49 The way this is envision to work is that an IPv6 application running 50 on an IPv6 only node and willing to send a packet to an IPv4 address 51 will simply create an IPv6 destination address made by appending the 52 well-known prefix with the IPv4 address and send this one on the 53 wire. 55 For example, if the well known prefix is ::FFFE:0:0/96, then an IPv6 56 only application willing to send a packet to 1.2.3.4 will simply send 57 it to the IPv6 address ::FFFE:1.2.3.4. 59 IPv6->IPv4 translators would advertise that well-known prefix or 60 shorter version of it, to their local routing system (IGP). 62 Note: it is not expected that this prefix would be advertised outside 63 of the IGPs in the Internet default free zone. Thus, it could be 64 deployed within an enterprise or by an ISP for its residential 65 customers. It is neither expected nor really desirable to see this 66 prefix advertised in BGP peerings. 68 2. Issues around address selection in outgoing connections. 70 RFC2766 section 4.2 says: 72 "...the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 73 query to the external DNS system unchanged, as well as an A query 74 for the same node. If an AAAA/A6 record exists for the destination, 75 this will be returned to NAT-PT which will forward it, also 76 unchanged, to the originating host. 78 If there is an A record for Node-C the reply also returns to the 79 NAT-PT. The DNS-ALG then, translates the reply adding the 80 appropriate PREFIX and forwards it to the originating device with 81 any IPv6 addresses that might have learned." 83 2.1 IPv6 node behind NAT-PT with DNS-ALG to dual stack node 85 Let's take the case of a node X behind a NAT-PT box trying to 86 communicate with a dual stack node Y outside of the NAT-PT domain for 87 which both A and AAAA addresses are published in the DNS. X will 88 issue a AAAA query for Y. The DNS contains a AAAA record for Y, this 89 AAAA record will be returned (unchanged) to X. The DNS contains also 90 a A record for Y, so the DNS-ALG, according to RFC2766, will create a 91 AAAA record to map it. So X will be returned 2 AAAA records, the 92 regular one and a translated one. 94 Later, RFC2766 says: 96 "NOTE: The prefix PREFIX::/96 is advertised in the stub domain by 97 the NAT-PT, and packets addressed to this PREFIX will be routed to 98 the NAT-PT. The pre-configured PREFIX only needs to be routable 99 within the IPv6 stub domain and as such it can be any routable 100 prefix that the network administrator chooses." 102 In practice, this means that PREFIX is taken out of X site /48 103 prefix. 105 So when X will initiate the connection to Y, it will apply the 106 address selection rules on the two IPv6 addresses returned by the 107 DNS. All things being equal, address selection will do a longest 108 prefix match, and as the translated IPv6 address of Y is in the same 109 prefix as X, this one will have precedence over the 'regular' IPv6 110 address of Y. As a consequence, X will choose a translated path to Y 111 when it could have chosen a direct native IPv6 path. 113 One possible way to avoid this issue is to require the DNS ALG to not 114 return the translated AAAA if a regular AAAA record actually exist. 115 There are some performance/time-out issues associated to this. 117 2.2 IPv6 node behind NAT-PT without DNS-ALG to dual stack node 119 Without DNS-ALG, node X will only receive the normal AAAA record for 120 Y and use IPv6 for its connection. Thus, with the well known prefix, 121 the problems described in section 2.1 do not exist. 123 2.3 Dual stack node behind NAT-PT with DNS-ALG to IPv4 node 125 RFC2766 clearly states that it is only applicable for IPv6-only 126 devices, but in practice, it is very difficult to know if nodes 127 behind a NAT-PT domain will be dual-stack or not. Most probably, 128 there will be a mixture of IPv4-only nodes, IPv6-only nodes and dual 129 stack nodes. Let's look at the case where a dual-stack node X behind 130 a NAT-PT + DNS-ALG box wants to communicate to an IPv4 only node Y 131 outside of the translator. Let's also make the hypothesis that X IPv4 132 address is a global one. This could be the case of an enterprise 133 network who is using IPv4 global address internally but, as those 134 IPv4 global addresses are a scarce resource, it has decided not to 135 allocate IPv4 global addresses to a new generation of devices. On 136 this network, there would be a mix of non-upgraded IPv4-only hosts, 137 dual-stack nodes and new generation IPv6-only devices. 139 When node X wants to initiate a communication with node Y, it will 140 typically issue DNS queries for AAAA and A records for Y. Y being 141 IPv4 only, only an A record exists in the DNS. 143 RFC2766 is not clear on how a DNS-ALG should treat answers to A 144 queries made by internal nodes. As a matter of fact, one could fear 145 that a careless DNS-ALG would also intercept them and translate them 146 into a AAAA form. In other words, nodes asking for a A record could 147 be returned a translated AAAA record instead. 149 Also, when X will ask for a AAAA (X is dual stack, so it would ask 150 for both), it would be returned a translated AAAA. So in any case, a 151 translated AAAA record will be returned to X. Nodes are usually 152 configure to prefer IPv6 over IPv4 when both are available, the 153 communication between X and Y will then takes place using the 154 translated path when the native IPv4 path would have worked. 156 A first approach to solve this problem is to make sure in the DNS-ALG 157 that if an A query is originating from inside, it would not be 158 translated. But, as the text above shows, this is good but not 159 enough. One step further would be for the DNS-ALG to recognize the 160 fact that X is asking for both A and AAAA, then infer that it should 161 be a query coming from a dual-stack host and not try to generate the 162 translated AAAA answer. 164 Another approach would be to make sure that only the IPv6-only device 165 will use the DNS-ALG, as recommended by RFC2766. This can be tricky 166 in practice and would require to isolate the IPv6-only device in one 167 part of the network. 169 2.4 Dual stack node behind NAT-PT without DNS-ALG to IPv4 node 171 Without DNS-ALG node X will only receive the normal A record for Y 172 and use IPv4 for its connection. Thus, with the well known prefix, 173 the problems described in section 2.3 do not exist. 175 3. Issues around DNS-sec 177 3.1 DNS-sec deployment with NAT-PR and DNS-ALG 179 Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- 180 sec. Actually there is a way to make it work, which is to mandate 181 that each node behind the NAT-PT box use 'AD is secure' and trust the 182 local recursive DNS resolver to verify the DNS signatures. This 183 effectively prevents node from performing their own verification and 184 impose a trust model that may or may not be acceptable. 186 -------------------------------------------------------------------- 187 => DNS-sec is only deployable within a NAT-PT domain with DNS-ALG if 188 nodes are willing to delegate signature verifications to the local 189 recursive DNS server. This is changing the basic trust model provided 190 by DNSsec where end-nodes can (if they want to) perform themselves 191 the signature verifications. 192 -------------------------------------------------------------------- 194 3.2 DNS-sec deployment with NAT-PT without DNS-ALG 196 In the absence of DNS-ALG, the DNS records are not modified and nodes 197 can, if they want, do the signature verifications themselves. 199 4. Scaling 201 4.1 Scaling NAT-PT with DNS-ALG 203 The way to scale NAT-PT with a DNS-ALG is for the DNS-ALG to allocate 204 different prefixes for different translators. The DNS-ALG could do 205 that in a round-robin way, used a pre-defined list or any kind of 206 hashing function. This would allow the DNS-ALG to monitor the 207 traffic and perform dynamic adjustments. This can be seen as dynamic 208 scaling. 210 4.2 Scaling NAT-PT without DNS-ALG 212 Without a DNS-ALG, the routing system perform the scaling of the 213 system. Each NAT-PT box can advertise only the subset of the IPv4 214 space it intend to cover. The maximum granularity one can achieve is 215 one box per IPv4 address destination. This can be seen as static 216 scaling. 218 5. Robustness 220 5.2 Robustness of NAT-PT with DNS-ALG 222 The DNS-ALG needs to actively monitor the NAT-PT boxes, to detect the 223 potential failure of one of them and remove it from the list of valid 224 translators. In practice, this means that the prefix associated to 225 that translator will not be used anymore by the DNS-ALG to respond to 226 DNS queries. For this to work, the DNS-ALG must set the TTL of the 227 DNS answer to zero and user applications are expected to respect that 228 TTL, i.e. not cache the name to address mapping, even for a short 229 time. With this system, new connections started after new name to 230 address resolution request intercepted by the DNS-ALG will work, 231 existing connections would hang and new connections that are using 232 the obsolete mapping would fail. 234 Note: this last point is important in this discussion. For example, 235 web browser that have to load different URLs pointing to the 'same' 236 place (e.g. many pictures on the same page) may be tempted to cache 237 the name to address resolution mapping even though the TTL is set to 238 zero. 240 5.3 Robustness of NAT-PT without DNS-ALG 242 Without the DNS ALG, the routing system can also provide robustness 243 to the system. NAT-PT boxes can be configured to announce the same 244 prefix, the routing system could either forward the traffic to the 245 nearest translator or perform some kind of load balancing between the 246 various boxes. If one of them dies, it stops announcing its prefix, 247 thus disappear automatically from the routing tables. new connections 248 will be redirected transparently to a new translator, but existing 249 connections would hang. 251 Instabilities in the routing system may end up sending packets 252 belonging to the same flow to different NAT-PT boxes. As NAT-PT is 253 stateful, this would end-up in broken connections. However, the IGP 254 announcing the routes to the NAT-PT boxes are usually rather stable, 255 so this may not be as big a problem as it first seems to be. Long 256 term connections would statistically be more affected than short term 257 connections. 259 6. Security considerations 261 Section 3. discusses the potential security impact of RFC2766 on 262 DNSsec. 264 7. Authors addresses 266 Alain Durand 267 SUN Microsystems, Inc 268 901 San Antonio Road 269 UMPK17-202 270 Palo Alto, CA 94303-4900 271 USA 272 Mail: Alain.Durand@sun.com 274 8. References 276 [NAT-PT] Tsirtsis, G., Srisuresh, P., 277 "Network Address Translation - Protocol Translation (NAT-PT)", 278 RFC 2766, February 2000