idnits 2.17.1 draft-ietf-v6ops-host-addr-availability-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 10, 2015) is 3032 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-01 == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-04 == Outdated reference: A later version (-02) exists of draft-tsvwg-quic-protocol-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations L. Colitti 3 Internet-Draft V. Cerf 4 Intended status: Best Current Practice Google 5 Expires: June 12, 2016 S. Cheshire 6 D. Schinazi 7 Apple Inc. 8 December 10, 2015 10 Host address availability recommendations 11 draft-ietf-v6ops-host-addr-availability-03 13 Abstract 15 This document recommends that networks provide general-purpose end 16 hosts with multiple global IPv6 addresses when they attach, and 17 describes the benefits of and the options for doing so. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 12, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3 56 3. Benefits of multiple addresses . . . . . . . . . . . . . . . 3 57 4. Problems with assigning a restricted number of addresses per 58 host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Overcoming limits using Network Address Translation . . . . . 5 60 6. Options for obtaining more than one address . . . . . . . . . 6 61 7. Number of addresses required . . . . . . . . . . . . . . . . 7 62 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Operational considerations . . . . . . . . . . . . . . . . . 8 64 9.1. Stateful addressing and host tracking . . . . . . . . . . 8 65 9.2. Address space management . . . . . . . . . . . . . . . . 9 66 9.3. Addressing link layer scalability issues via IP routing . 9 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 13.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 In most aspects, the IPv6 protocol is very similar to IPv4. This 78 similarity can create a tendency to think of IPv6 as 128-bit IPv4, 79 and thus lead network designers and operators to apply identical 80 configurations and operational practices to both. This is generally 81 a good thing because it eases the transition to IPv6 and the 82 operation of dual-stack networks. However, in some areas it can lead 83 to carrying over IPv4 practices that are not appropriate in IPv6 due 84 to significant differences between the protocols. 86 One such area is IP addressing, particularly IP addressing of hosts. 87 This is substantially different because unlike IPv4 addresses, IPv6 88 addresses are not a scarce resource. In IPv6, each link has a 89 virtually unlimited amount of address space [RFC7421]. Thus, unlike 90 IPv4, IPv6 networks are not forced by address availability 91 considerations to assign only one address per host. On the other 92 hand, assigning multiple addresses has many benefits including 93 application functionality and simplicity, privacy, future 94 applications, and the ability to deploy the Internet without the use 95 of NAT. Assigning only one IPv6 address per host negates these 96 benefits. 98 This document describes the benefits of assigning multiple addresses 99 per host and the problems with not doing so. It recommends that 100 networks provide general-purpose end hosts with multiple global 101 addresses when they attach, and lists current options for doing so. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 110 2. Common IPv6 deployment model 112 IPv6 is designed to support multiple addresses, including multiple 113 global addresses, per interface ([RFC4291] section 2.1, [RFC6434] 114 section 5.9.4). Today, many general-purpose IPv6 hosts are 115 configured with three or more addresses per interface: a link-local 116 address, a stable address (e.g., using EUI-64 or Opaque Interface 117 Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and 118 possibly one or more temporary or non-temporary addresses assigned 119 using DHCPv6 [RFC3315]. 121 In most general-purpose IPv6 networks, including all 3GPP networks 122 ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC 123 [RFC4862], IPv6 hosts have the ability to configure additional IPv6 124 addresses from the link prefix(es) without explicit requests to the 125 network. 127 3. Benefits of multiple addresses 129 Today, there are many host functions that require more than one IP 130 address to be available to the host: 132 o Privacy addressing to prevent tracking by off-network hosts 133 [RFC4941]. 135 o Multiple processors inside the same device. For example, in many 136 mobile devices both the application processor and baseband 137 processor need to communicate with the network, particularly for 138 recent technologies like ePDG. 140 o Extending the network (e.g., "tethering"). 142 o Running virtual machines on hosts. 144 o Translation-based transition technologies such as 464XLAT 145 [RFC6877] that provide IPv4 over IPv6. Some of these require the 146 availability of a dedicated IPv6 address in order to determine 147 whether inbound packets are translated or native ([RFC6877] 148 section 6.3). 150 o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-ila]. 152 o Future applications (e.g., per-application IPv6 addresses [TARP]). 154 Examples of how the availability of multiple addresses per host has 155 already allowed substantial deployment of new applications without 156 explicit requests to the network are: 158 o 464XLAT. 464XLAT is usually deployed within a particular network, 159 and in this model the operator can ensure that the network is 160 appropriately configured to provide the CLAT with the additional 161 IPv6 address it needs to implement 464XLAT. However, there are 162 deployments where the PLAT (i.e., NAT64) is provided as a service 163 by a different network, without the knowledge or cooperation of 164 the residential ISP (e.g., the IPv6v4 Exchange Service 165 ). This type of 166 deployment is only possible because those residential ISPs provide 167 multiple IP addresses to their users, and thus those users can 168 freely obtain the extra IPv6 address required to run 464XLAT. 170 o /64 sharing [RFC7278]. When the topology supports it, this is a 171 way to provide IPv6 tethering without needing to wait for network 172 operators to deploy DHCPv6 PD, which is only available in 3GPP 173 release 10 ([RFC6459] section 5.3). 175 4. Problems with assigning a restricted number of addresses per host 177 Assigning a restricted number of addresses per host implies that 178 functions that require multiple addresses will either be unavailable 179 (e.g., if the network provides only one IPv6 address per host, or if 180 the host has reached the limit of the number of addresses available), 181 or that the functions will only be available after an explicit 182 request to the network is granted. The necessity of explicit 183 requests has the following drawbacks: 185 o Increased latency, because a provisioning operation, and possibly 186 human intervention with an update to the service level agreement, 187 must complete before the functionality is available. 189 o Uncertainty, because it is not known in advance if a particular 190 operation function will be available. 192 o Complexity, because implementations need to deal with failures and 193 somehow present them to the user. Failures may manifest as 194 timeouts, which may be slow and frustrating to users. 196 o Increased load on the network's provisioning servers. 198 Some operators may desire to configure their networks to limit the 199 number of IPv6 addresses per host. Reasons might include hardware 200 limitations (e.g., TCAM or neighbor cache table size constraints), 201 business models (e.g., a desire to charge the network's users on a 202 per-device basis), or operational consistency with IPv4 (e.g., an IP 203 address management system that only supports one address per host). 204 However, hardware limitations are expected to ease over time, and an 205 attempt to generate additional revenue by charging per device may 206 prove counterproductive if customers respond (as they did with IPv4) 207 by using NAT, which results in no additional revenue, but leads to 208 more operational problems and higher support costs. 210 5. Overcoming limits using Network Address Translation 212 These limits can mostly be overcome by end hosts by using NAT, and 213 indeed in IPv4 most of these functions are provided by using NAT on 214 the host. Thus, the limits could be overcome in IPv6 as well by 215 implementing NAT66 on the host. 217 Unfortunately NAT has well-known drawbacks. For example, it causes 218 application complexity due to the need to implement NAT traversal. 219 It hinders development of new applications. On mobile devices, it 220 reduces battery life due to the necessity of frequent keepalives, 221 particularly for UDP. Applications using UDP that need to work on 222 most of the Internet are forced to send keepalives at least every 30 223 seconds . For example, the QUIC protocol uses a 15-second keepalive 225 [I-D.tsvwg-quic-protocol]. Other drawbacks of NAT are well known and 226 documented [RFC2993]. While IPv4 NAT is inevitable due to the 227 limited amount of IPv4 space available, that argument does not apply 228 to IPv6. Guidance from the IAB is that deployment of IPv6 NAT is not 229 desirable [RFC5902]. 231 The desire to overcome the problems listed in Section 4 without 232 disabling any features has resulted in developers implementing IPv6 233 NAT. There are fully-stateful address+port NAT66 implementations in 234 client operating systems today: for example, Linux has supported 235 NAT66 since late 2012 . A popular software 237 hypervisor also recently implemented NAT66 to work around these 238 issues . Wide 239 deployment of networks that provide a restricted number of addresses 240 will cause proliferation of NAT66 implementations. 242 This is not a desirable outcome. It is not desirable for users 243 because they may experience application brittleness. It is likely 244 not desirable for network operators either, as they may suffer higher 245 support costs, and even when the decision to assign only one IPv6 246 address per device is dictated by the network's business model, there 247 may be little in the way of incremental revenue, because devices can 248 share their IPv6 address with other devices. Finally, it is not 249 desirable for operating system manufacturers and application 250 developers, who will have to build more complexity, lengthening 251 development time and/or reducing the time spent on other features. 253 Indeed, it could be argued that the main reason for deploying IPv6, 254 instead of continuing to scale the Internet using only IPv4 and 255 large-scale NAT44, is because doing so can provide all the hosts on 256 the planet with end-to-end connectivity that is constrained not by 257 accidental technical limitations, but only by intentional security 258 policies. 260 6. Options for obtaining more than one address 262 Multiple IPv6 addresses can be obtained in the following ways: 264 o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows 265 hosts to create global IPv6 addresses on demand by simply forming 266 new addresses from the global prefix assigned to the link. 268 o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 269 clients only ask for one non-temporary address, but the protocol 270 allows requesting multiple temporary and even multiple non- 271 temporary addresses, and the server could choose to assign the 272 client multiple addresses. It is also technically possible for a 273 client to request additional addresses using a different DUID, 274 though the DHCPv6 specification implies that this is not expected 275 behavior ([RFC3315] section 9). The DHCPv6 server will decide 276 whether to grant or reject the request based on information about 277 the client, including its DUID, MAC address, and so on. 279 o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client 280 to request and be delegated a prefix, from which it can 281 autonomously form other addresses. If the prefix is shorter than 282 /64, it can be divided into multiple subnets which can be further 283 delegated to downstream clients. If the prefix is a /64, it can 284 be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing 285 [RFC7278], but it cannot be further subdivided, as a prefix longer 286 than /64 is outside the current IPv6 specifications [RFC7421]. 288 +--------------------------+-------+-------------+--------+---------+ 289 | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | 290 | | | IA_NA / | PD | | 291 | | | IA_TA | | | 292 +--------------------------+-------+-------------+--------+---------+ 293 | Extend network | Yes | No | Yes | Yes | 294 | | | | | (NAT44) | 295 | "Unlimited" endpoints | Yes* | Yes* | No | No | 296 | Stateful, request-based | No | Yes | Yes | Yes | 297 | Immune to layer 3 on- | No | Yes | Yes | Yes | 298 | link resource exhaustion | | | | | 299 | attacks | | | | | 300 +--------------------------+-------+-------------+--------+---------+ 302 [*] Subject to network limitations, e.g., ND cache entry size limits. 304 Table 1: Comparison of multiple address assignment options 306 7. Number of addresses required 308 If we itemize the use cases from section Section 3, we can estimate 309 the number of addresses currently used in normal operations. In 310 typical implementations, privacy addresses use up to 8 addresses - 311 one per day ([RFC4941] section 3.5). Current mobile devices may 312 typically support 8 clients, with each one requiring one or more 313 addresses. A client might choose to run several virtual machines. 314 Current implementations of 464XLAT require use of a separate address. 315 Some devices require another address for their baseband chip. Even a 316 host performing just a few of these functions simultaneously might 317 need on the order of 20 addresses at the same time. Future 318 applications designed to use an address per application or even per 319 resource will require many more. These will not function on networks 320 that enforce a hard limit on the number of addresses provided to 321 hosts. 323 8. Recommendations 325 In order to avoid the problems described above, and preserve the 326 Internet's ability to support new applications that use more than one 327 IPv6 address, it is RECOMMENDED that IPv6 network deployments provide 328 multiple IPv6 addresses from each prefix to general-purpose hosts 329 when they connect to the network. To support future use cases, it is 330 RECOMMENDED to not impose a hard limit on the size of the address 331 pool assigned to a host. If the network requires explicit requests 332 for address space (e.g., if it requires DHCPv6 to connect), it is 333 RECOMMENDED that the network assign a /64 prefix to every host (e.g., 334 via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient 335 number of addresses (e.g. 32) would accommodate current clients but 336 sets a limit on the number of addresses available to hosts when they 337 attach and would limit the development of future applications. 338 Assigning prefixes longer than a /64 will limit the flexibility of 339 the host to further assign addresses to any internal functions, 340 virtual machines, or downstream clients that require address space - 341 for example, by not allowing the use of SLAAC. 343 9. Operational considerations 345 9.1. Stateful addressing and host tracking 347 Some network operators - often operators of networks that provide 348 services to third parties such as university campus networks - are 349 required to track which IP addresses are assigned to which hosts on 350 their network. Maintaining persistent logs that map user IP 351 addresses and timestamps to hardware identifiers such as MAC 352 addresses may be used to avoid liability for copyright infringement 353 or other illegal activity. 355 It is worth noting that this requirement can be met without using 356 stateful addressing mechanisms such as DHCPv6. For example, it is 357 possible to maintain these mappings by scraping IPv6 neighbor tables, 358 as routers typically allow periodic dumps of the neighbor cache via 359 SNMP or other means, and many can be configured to log every change 360 to the neighbor cache. 362 It is also worth noting that without L2 edge port security, hosts are 363 still able to choose their own addresses - DHCPv6 does not offer any 364 enforcement of what addresses a host is allowed to use. Such 365 guarantees can only be provided by link-layer security mechanisms 366 that enforce that particular IPv6 addresses are used by particular 367 link-layer addresses (for example, SAVI [RFC7039]). If those 368 mechanisms are available, it is possible to use them to provide 369 tracking. This form of tracking is much more secure and reliable 370 than DHCP server logs because it operates independently of how 371 addresses are allocated. Additionally, attempts to track this sort 372 of information via DHCPv6 are likely to become decreasingly viable 373 due to ongoing efforts to improve the privacy of DHCP 374 [I-D.ietf-dhc-anonymity-profile]. 376 Thus, host tracking does not necessarily require the use of stateful 377 address assignment mechanisms such as DHCPv6. Indeed, many large 378 enterprise networks, including the enterprise networks of the 379 authors' employers, are fully dual-stack but do not currently use or 380 support DHCPv6. The authors are directly aware of several networks 381 that operate in this way, including Universities of Loughborough, 382 Minnesota, Reading, Southampton, Wisconsin and Imperial College 383 London. 385 9.2. Address space management 387 In IPv4, all but the world's largest networks can be addressed using 388 private space [RFC1918], with each host receiving one IPv4 address. 389 Many networks can be numbered in 192.168.0.0/16 which has roughly 64k 390 addresses. In IPv6, that is equivalent to a /48, with each of 64k 391 hosts receiving a /64 prefix. Under current RIR policies, a /48 is 392 easy to obtain for an enterprise network. 394 Networks that need a bigger block of private space use 10.0.0.0/8, 395 which has roughly 16 million addresses. In IPv6, that is equivalent 396 to a /40, with each host receiving /64 prefix. Enterprises of such 397 size can easily obtain a /40 under current RIR policies. 399 Currently, residential users typically receive one IPv4 address and a 400 /48, /56 or /60 IPv6 prefix. While such networks do not provide 401 enough space to assign a /64 per host, such networks almost 402 universally use SLAAC, and thus do not pose any particular limit to 403 the number of addresses hosts can use. 405 Unlike IPv4 where addresses came at a premium, in all these networks, 406 there is enough IPv6 address space to supply clients with multiple 407 IPv6 addresses. 409 9.3. Addressing link layer scalability issues via IP routing 411 The number of IPv6 addresses on a link has direct impact for 412 networking infrastructure nodes (routers, switches) and other nodes 413 on the link. Setting aside exhaustion attacks via Layer 2 address 414 spoofing, every (Layer 2, IP) address pair impacts networking 415 hardware requirements in terms of memory, MLD snooping, solicited 416 node multicast groups, etc. Many of these costs are incurred by 417 neighboring hosts. 419 Hosts on such networks that create unreasonable numbers of addresses 420 risk impairing network connectivity for themselves and other hosts on 421 the network, and in extreme cases (e.g., hundreds or thousands of 422 addresses) may even find their network access restricted by denial- 423 of-service protection mechanisms. We expect these scaling 424 limitations to change over time as hardware and applications evolve. 425 However, switching to a DHCPv6 PD model with one /64 prefix per host 426 resolves these scaling limitations, with only one routing entry and 427 one ND cache entry per device on the network. 429 Also, a DHCPv6 PD model with a dedicated /64 per host makes it 430 possible for the host not to assign global IPv6 addresses directly to 431 its physical network interface, but instead to assign them to an 432 internal interface such as a loopback interface. This obviates the 433 need to perform Neighbour Discovery and Duplicate Address Detection 434 for anything other than the link-local address on its physical 435 network interface, reducing network traffic. 437 10. Acknowledgements 439 The authors thank Tore Anderson, Brian Carpenter, David Farmer, 440 Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark 441 Smith, Sander Steffann and James Woodyatt for their input and 442 contributions. 444 11. IANA Considerations 446 This memo includes no request to IANA. 448 12. Security Considerations 450 None so far. 452 13. References 454 13.1. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 13.2. Informative References 463 [I-D.herbert-nvo3-ila] 464 Herbert, T., "Identifier-locator addressing for network 465 virtualization", draft-herbert-nvo3-ila-01 (work in 466 progress), October 2015. 468 [I-D.ietf-dhc-anonymity-profile] 469 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 470 profile for DHCP clients", draft-ietf-dhc-anonymity- 471 profile-04 (work in progress), October 2015. 473 [I-D.tsvwg-quic-protocol] 474 Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and 475 Reliable Transport for HTTP/2", draft-tsvwg-quic- 476 protocol-01 (work in progress), July 2015. 478 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 479 and E. Lear, "Address Allocation for Private Internets", 480 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 481 . 483 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 484 DOI 10.17487/RFC2993, November 2000, 485 . 487 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 488 C., and M. Carney, "Dynamic Host Configuration Protocol 489 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 490 2003, . 492 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 493 Host Configuration Protocol (DHCP) version 6", RFC 3633, 494 DOI 10.17487/RFC3633, December 2003, 495 . 497 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 498 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 499 2006, . 501 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 502 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 503 2006, . 505 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 506 Address Autoconfiguration", RFC 4862, 507 DOI 10.17487/RFC4862, September 2007, 508 . 510 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 511 Extensions for Stateless Address Autoconfiguration in 512 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 513 . 515 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 516 IPv6 Network Address Translation", RFC 5902, 517 DOI 10.17487/RFC5902, July 2010, 518 . 520 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 521 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 522 2011, . 524 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 525 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 526 Partnership Project (3GPP) Evolved Packet System (EPS)", 527 RFC 6459, DOI 10.17487/RFC6459, January 2012, 528 . 530 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 531 Combination of Stateful and Stateless Translation", 532 RFC 6877, DOI 10.17487/RFC6877, April 2013, 533 . 535 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 536 "Source Address Validation Improvement (SAVI) Framework", 537 RFC 7039, DOI 10.17487/RFC7039, October 2013, 538 . 540 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 541 Interface Identifiers with IPv6 Stateless Address 542 Autoconfiguration (SLAAC)", RFC 7217, 543 DOI 10.17487/RFC7217, April 2014, 544 . 546 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 547 /64 Prefix from a Third Generation Partnership Project 548 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 549 DOI 10.17487/RFC7278, June 2014, 550 . 552 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 553 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 554 Boundary in IPv6 Addressing", RFC 7421, 555 DOI 10.17487/RFC7421, January 2015, 556 . 558 [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for 559 Related Processes: Improved Firewalling by Using IPv6 and 560 Multiple Addresses per Host", August 2001. 562 Authors' Addresses 564 Lorenzo Colitti 565 Google 566 Roppongi 6-10-1 567 Minato, Tokyo 106-6126 568 JP 570 Email: lorenzo@google.com 571 Vint Cerf 572 Google 573 1875 Explorer St 574 10th Floor 575 Reston, VA 20190 576 US 578 Email: vint@google.com 580 Stuart Cheshire 581 Apple Inc. 582 1 Infinite Loop 583 Cupertino, CA 95014 584 US 586 Email: cheshire@apple.com 588 David Schinazi 589 Apple Inc. 590 1 Infinite Loop 591 Cupertino, CA 95014 592 US 594 Email: dschinazi@apple.com