idnits 2.17.00 (12 Aug 2021) /tmp/idnits20927/draft-thaler-ipv6-saf-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-mrw-nat66 has been published as RFC 6296 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational March 14, 2011 5 Expires: September 15, 2011 7 Source Address Finding (SAF) for IPv6 Translation Mechanisms 8 draft-thaler-ipv6-saf-03.txt 10 Abstract 12 There are various recent proposals that would result in IPv6 13 translation becoming permanent. RFC 3424 discusses UNilateral Self- 14 Address Fixing (UNSAF) mechanisms which are required for applications 15 to work with most translation schemes, points out a number of 16 problems with them, and requires an exit strategy for any UNSAF 17 mechanism. This document discusses an alternative to UNSAF 18 mechanisms should IPv6 translation become permanent. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 15, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. IPv6 Translation . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IPv6 Translation Without UNSAF . . . . . . . . . . . . . . . . 4 57 3.1. Evaluation of Architectural Issues . . . . . . . . . . . . 5 58 3.2. Requirements for SAF Mechanisms . . . . . . . . . . . . . 6 59 3.3. DHCPv6 Option as a SAF Mechanism . . . . . . . . . . . . . 7 60 3.3.1. DHCPv6 Server Configuration . . . . . . . . . . . . . 8 61 3.3.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . 9 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Many applications and protocols use one or more addresses of the 72 local machine, e.g., to send in an application protocol exchange or 73 to advertise a public address at which it will accept connections. 75 RFC 2993 [RFC2993] discusses architectural implications of Network 76 Address Translation (NAT). One of the implications of translation is 77 that in general the address that must be used by other nodes to reach 78 a destination is not the address assigned to an interface on the 79 destination, where the destination's applications and protocols would 80 naturally find it. As a result, NAT generally requires a mechanism 81 whereby an endpoint can determine the address by which it is known to 82 other endpoints, and then "fix" its own messages to use that address 83 instead of the one(s) it would normally use. This category of 84 mechanisms is known as UNilateral Self-Address Fixing (UNSAF). 86 RFC 3424 [RFC3424] discusses architectural implications of UNSAF 87 mechanisms, and concludes that they are not appropriate as long term 88 fixes and recommends that any UNSAF proposal require, among other 89 things, an exit strategy. Since NAT mechanisms generally require 90 UNSAF mechanisms, an exit strategy for an UNSAF proposal often 91 requires an exit strategy for the NAT mechanism motivating it. 93 2. IPv6 Translation 95 The notion of IPv4-IPv6 translation (e.g., NAT-PT [RFC2766]) first 96 introduced the NAT problems into IPv6 and motivated UNSAF mechanisms 97 in IPv6. Although NAT-PT was deprecated ([RFC4966]), the notion of 98 IPv4-IPv6 translation has become even more important. There is a 99 fairly clear exit strategy (although the timeframe of an exit is not 100 at all clear), which is that IPv4-IPv6 translation use decreases as 101 IPv4-only nodes decrease over time. As a result, the exit strategy 102 of any resulting UNSAF mechanisms is that their use declines as IPv4- 103 IPv6 translation declines. 105 Recently however there has been discussion of the possibility of 106 IPv6-IPv6 translation (e.g., NPT66 [I-D.mrw-nat66] to address 107 renumbering pains, Six/One [I-D.vogt-rrg-six-one] to address routing 108 scalability, etc.). Such proposals, if adopted, are not proposed as 109 short term mechanisms but rather as more permanent changes to the 110 architecture. As such, if UNSAF mechanisms are required, the exit 111 strategy cannot be simply based on declining IPv6-IPv6 translation. 113 3. IPv6 Translation Without UNSAF 115 In this section, we focus primarily on IPv6-IPv6 translation, 116 although there may be cases where the same concepts might be 117 applicable to IPv4-IPv6 translation or IPv4-IPv4 translation. 119 While translation in general requires UNSAF mechanisms, some uses of 120 translation do not. UNSAF mechanisms are needed whenever the address 121 reachable by outside parties is not an address of the local machine. 122 Hence any use of translation whereby the address reachable by outside 123 parties is still an address that appears to be assigned to some 124 interface on the machine, does not require UNSAF mechanisms. For 125 example, the Host Identity Protocol (HIP) [RFC5201] uses translation 126 in this respect. The address seen by applications is in fact not the 127 address used on the wire, but is translated by the HIP layer on both 128 the sender and the receiver. 130 There are two key requirements for the translation mechanism: 131 1. The translation is reversible without loss of information, and 132 2. The address is presented by the host to upper layers in the same 133 way as a normal IP address. 135 When these requirements are met, reversible translation can be 136 compared to (and contrasted with) a tunnel with header compression. 137 To reverse translation, both translators must have the information 138 necessary to perform the translation, which requires some 139 configuration or per-host signaling mechanism (e.g., DHCP, as opposed 140 to a per-flow signaling mechanism as HIP does) for learning an 141 address to configure on an interface, which obviates the need for 142 applications to use an UNSAF mechanism above the transport layer. We 143 will refer to this concept as Self-Address Finding (SAF) to 144 distinguish it from UNSAF mechanisms. Note that "finding" is 145 intentionally used here instead of "fixing" as in UNSAF; since the 146 address found is actually used by IP and higher layers, there is 147 nothing to "fix" up higher. 149 Tunneling mechanisms, however, have deployment incentive issues (as 150 pointed out in [RFC5218]) in that they require both ends to be 151 changed before either end benefits. Translation mechanisms such as 152 NAT, on the other hand, have the advantage of being unilaterally 153 deployable, at the expense of breaking some applications. For 154 additional discussion, see [RFC5902]. 156 Reversible IPv6-IPv6 translation can be initially deployed 157 unilaterally (at the expense of breaking some applications) at a 158 translation middlebox without touching end hosts, avoiding the 159 deployment incentive issues with tunneling. End-to-end connectivity 160 can then be restored once the host is able to learn the external 161 address and configure it on a virtual interface; hence, there is a 162 further incentive built-in that restores the end-to-end model. This 163 provides an exit strategy that does not require an UNSAF mechanism or 164 result in the issues discussed in [RFC3424]. 166 3.1. Evaluation of Architectural Issues 168 Regarding issues with NAT mechanisms raised in [RFC2993]: 169 o Per-flow state in the middlebox (scaling, multihoming, single 170 point-of-failure, etc): Reversible translation can be done without 171 any per-flow state in the middlebox. NPT66 and Six/One are 172 examples of this. 173 o Inhibit IPsec: If translation and reversing can be done below 174 IPsec, IPsec works normally. (Or if translation and reversing is 175 done within IPsec as HIP does, IPsec also works.) 176 o Address sharing (NAPT) inhibits other transport protocols: 177 Reversible translation can be done without address sharing, 178 allowing arbitrary transport protocols to work. 180 Regarding issues with UNSAF mechanisms raised in [RFC3424]: 181 o No unique outside: When nested translators exist, there are 182 multiple outside areas and hence multiple addresses by which one 183 is reachable by different peers. Reversible translation does not 184 change this. This means that a node must be able to discover the 185 address assigned by each translator in front of it. 186 o Circumventing firewalls: Firewalls are orthogonal to reversible 187 translation. SAF mechanisms should not circumvent firewalls. 188 Since translators can be stateless, there is no need for periodic 189 messages purely to maintain state in a translator or to implement 190 a SAF mechanism. 191 o Timeout issues of address assignment in middlebox: Since 192 translators can be stateless, there is no state to time out. 193 o Fate sharing when a server separate from the middlebox is used: 194 Like UNSAF mechanisms, SAF mechanisms could either use a server 195 separate from the middle box or communicate directly with the 196 middlebox itself. Communicating with a server on the Internet, as 197 protocols such as STUN [RFC5389] do, without any support from the 198 translator, generally only allows discovering the address assigned 199 by the outermost translator (i.e., the address seen by the server 200 outside), not each cascaded translator. Furthermore, 201 communicating with a remote server results in depending on 202 reachability all the way to that server, whereas the desired 203 communication may be much closer and otherwise be possible even 204 when the server is unreachable. Hence the use of an external 205 server is not recommended for SAF mechanisms. 207 3.2. Requirements for SAF Mechanisms 209 From the above discussion, we obtain the following requirements for 210 SAF mechanisms. 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC 2119 [RFC2119]. 216 1. Discovery: A SAF mechanism MUST allow a node to find the 217 addresses assigned by all translators it is behind. 218 Specifically, if the node is behind multiple cascaded 219 translators, such that there is no unique "outside", then the SAF 220 mechanism MUST allow the node to learn the address it will appear 221 as within each "outside" area. 223 This is easier to accomplish with a reversible translation, which 224 can be stable over time, than with NAPT mechanisms today that 225 require dynamic learning. For example, it could be done by the 226 node learning the effective (taking potentially multiple levels 227 of translation into account) rule for translation between its 228 local area and a particular outside area, and then computing its 229 addresses itself. As long as the translation algorithm and the 230 topology do not change, the node's addresses will not change. 231 This is analogous to a normal IP address of a node being stable 232 as long as the network isn't renumbered. 233 2. Staleness: A SAF mechanism MUST allow a node to know when to stop 234 using the address (e.g., if the assigned address changes due to 235 an ISP change). That is, a SAF proposal MUST specify what a node 236 uses as the ValidLifetime and the PreferredLifetime of an address 237 found. 238 3. Multihoming: A SAF mechanism MUST support a node being connected 239 to a network with multiple equivalent translators, meaning that 240 the same translation would be done regardless of the path taken. 241 In other words, it MUST NOT assume that it gets a unique address 242 from every translator. This is not a requirement that there be 243 such translators (e.g., egress routers on opposite sides of a 244 continent are not necessarily expected to translate to the same 245 prefix, only that if two translators are configured to translate 246 to the same prefix, then the SAF mechanism should support this). 247 4. Privacy: A SAF mechanism SHOULD support temporary addresses 248 [RFC3041] in addition to public addresses. 249 5. Security: A SAF mechanism SHOULD support Cryptographically 250 Generated Addresses (CGAs) [RFC3972]. 251 6. Fate-Sharing: A SAF mechanism SHOULD allow a node discover the 252 addresses assigned by translators even when the network behind 253 them is currently unreachable. 255 3.3. DHCPv6 Option as a SAF Mechanism 257 This section specifies the use of a DHCPv6 option as a SAF mechanism 258 for use with NPT66 [I-D.mrw-nat66]. 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | OPTION_SAF | option-len | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ ~ 266 ~ mapping 1 (28 octets) ~ 267 ~ ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 ~ ~ 270 ~ mapping 2 (28 octets) ~ 271 ~ ... ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 option-code OPTION_SAF (TBD). 276 option-len Length of the SAF option in octets (not including the 277 size of the option-code and option-len fields). The number of 278 prefix mappings in this option is thus given by (option-len / 28). 280 mapping n A 28-byte mapping, as specified below. This is replicated 281 once for each prefix mapping to be included in the option. 283 0 1 2 3 284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | preferred-lifetime | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | valid-lifetime | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | ext-pfx-len | int-pfx-len | route-length |resvd|prf|resvd| 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | external IPv6 prefix | 293 | (8 octets) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | internal IPv6 prefix | 296 | (8 octets) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 preferred-lifetime The preferred lifetime for the mapping in the 299 option, expressed in units of seconds. The preferred lifetime of 300 a virtual address is the minimum of this value, and the preferred 301 lifetime of the physical address from which it was derived. 303 valid-lifetime The valid lifetime for the mapping in the option, 304 expressed in units of seconds. The valid lifetime of a virtual 305 address is the minimum of this value, and the valid lifetime of 306 the physical address from which it was derived. 308 ext-pfx-len The prefix length in bits of the external prefix. 310 int-pfx-len The prefix length in bits of the internal prefix. 312 route-length The prefix length in bits of the route for destination 313 addresses usable with virtual addresses created using this 314 mapping. 316 resvd Reserved. MUST be 0, and MUST be ignored by DHCPv6 clients. 318 prf Route Preference. The 2-bit preference of the route. This 319 value is used as specified in [RFC4191]. 321 external IPv6 prefix The external IPv6 prefix, out of which the host 322 can derive virtual addresses. 324 internal IPv6 prefix The internal IPv6 prefix. For each physical 325 IPv6 address a client has in this prefix on the interface over 326 which this option was received, it can construct a virtual 327 address. 329 3.3.1. DHCPv6 Server Configuration 331 To use this mechanism, a DHCPv6 server is configured with a set of 332 translation configuration information that an end host can use to 333 derive externally-visible addresses from its own physical IPv6 334 addresses. 336 When nested translators exist, there are multiple outside areas and 337 hence multiple addresses by which one is reachable by different 338 peers. It is RECOMMENDED that a mapping for each be configured. For 339 example, if internal prefix X is mapped to prefix Y, which is then 340 mapped to prefix Z, the DHCPv6 option should contain mappings for 341 X<->Y with route-length equal to the prefix length of Y, and X<->Z 342 with route-length of 0, so that it can statelessly communicate with 343 other hosts in prefix Y using a virtual address from prefix Y, and 344 also statelessly communicate with hosts on the IPv6 Internet using a 345 virtual address from prefix Z. 347 3.3.2. DHCPv6 Client Behavior 349 To use this mechanism, a DHCPv6 server is configured with a set of 350 translation configuration information that an end host can use to 351 derive externally-visible addresses from its own physical IPv6 352 addresses, and then add those externally-visible addresses on a 353 virtual interface. That is, for each mapping between an internal 354 prefix and an external prefix, a DHCPv6 client does the following. 356 For each physical IPv6 address it has that falls within the internal 357 prefix and is on the interface over which this option was received, 358 it constructs a virtual external address using the translation 359 algorithm specified in [I-D.mrw-nat66] section 3.2, and assigns the 360 virtual address to a virtual interface. 362 The client must also use some means to ensure that the virtual 363 addresses are eligible for source address selection when sending to 364 external destinations. For example, the client constructs a route to 365 a destination prefix based on the external IPv6 prefix, truncated or 366 0-extended to the route-length, and adds the route on the virtual 367 interface. 369 4. Security Considerations 371 NATs and UNSAF mechanisms generally interfere with security 372 mechanisms because they change the addresses and/or content of 373 messages exchanged. This document discusses requirements for SAF 374 mechanisms that avoid these issues. 376 5. IANA Considerations 378 IANA is requested to a DHCPv6 option code value of TBD to the SAF 379 option from the DHCPv6 option code space defined in Section 24.3 of 380 [RFC3315]. 382 6. References 384 6.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 390 Stateless Address Autoconfiguration in IPv6", RFC 3041, 391 January 2001. 393 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 394 and M. Carney, "Dynamic Host Configuration Protocol for 395 IPv6 (DHCPv6)", RFC 3315, July 2003. 397 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 398 RFC 3972, March 2005. 400 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 401 More-Specific Routes", RFC 4191, November 2005. 403 6.2. Informative References 405 [I-D.mrw-nat66] 406 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 407 Translation", draft-mrw-nat66-12 (work in progress), 408 March 2011. 410 [I-D.vogt-rrg-six-one] 411 Vogt, C., "Six/One: A Solution for Routing and Addressing 412 in IPv6", draft-vogt-rrg-six-one-02 (work in progress), 413 October 2009. 415 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 416 Translation - Protocol Translation (NAT-PT)", RFC 2766, 417 February 2000. 419 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 420 November 2000. 422 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 423 Self-Address Fixing (UNSAF) Across Network Address 424 Translation", RFC 3424, November 2002. 426 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 427 Address Translator - Protocol Translator (NAT-PT) to 428 Historic Status", RFC 4966, July 2007. 430 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 431 "Host Identity Protocol", RFC 5201, April 2008. 433 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 434 Protocol?", RFC 5218, July 2008. 436 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 437 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 438 October 2008. 440 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 441 IPv6 Network Address Translation", RFC 5902, July 2010. 443 Author's Address 445 Dave Thaler 446 Microsoft Corporation 447 One Microsoft Way 448 Redmond, WA 98052 449 USA 451 Phone: +1 425 703 8835 452 Email: dthaler@microsoft.com