idnits 2.17.1 draft-templin-v6ops-isops-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 (May 20, 2011) is 4697 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 1009, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-00 == Outdated reference: A later version (-12) exists of draft-templin-aero-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational May 20, 2011 5 Expires: November 21, 2011 7 Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 8 draft-templin-v6ops-isops-03.txt 10 Abstract 12 Many end user sites in the Internet today still have predominantly 13 IPv4 internal infrastructures. These sites range in size from small 14 home/office networks to large corporate enterprise networks, but 15 share the commonality that IPv4 continues to provide satisfactory 16 internal routing and addressing services for most applications. As 17 more and more IPv6-only services are deployed in the Internet, 18 however, end user devices within such sites will increasingly require 19 at least basic IPv6 functionality for external access. It is also 20 expected that more and more IPv6-only devices will be deployed within 21 the site over time. This document therefore provides operational 22 guidance for deployment of IPv6 within predominantly IPv4 sites using 23 the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 21, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Enabling IPv6 Services using ISATAP . . . . . . . . . . . . . 3 61 3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 5 63 3.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 5 64 3.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 6 65 3.4. Reference Operational Scenario - Shared Prefix Model . . . 6 66 3.5. Reference Operational Scenario - Individual Prefix 67 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. SLAAC Site Administration Guidance . . . . . . . . . . . . 12 69 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 13 70 4. DHCPv6 Services . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 15 72 4.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 15 73 4.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 15 74 4.4. Reference Operational Scenario - No Prefix Model . . . . . 16 75 4.5. On-Demand Dynamic Routing for DHCP . . . . . . . . . . . . 19 76 4.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 20 77 5. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 20 78 6. Site Renumbering Considerations . . . . . . . . . . . . . . . 20 79 7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 21 80 8. Anycast Considerations . . . . . . . . . . . . . . . . . . . . 22 81 9. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 22 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 87 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 1. Introduction 92 End user sites in the Internet today currently use IPv4 routing and 93 addressing internally for core operating functions such as web 94 browsing, filesharing, network printing, e-mail, teleconferencing and 95 numerous other site-internal networking services. Such sites 96 typically have an abundance of public or private IPv4 addresses for 97 internal networking, and are separated from the public Internet by 98 firewalls, packet filtering gateways, proxies, address translators 99 and other site border demarcation devices. To date, such sites have 100 had little incentive to enable IPv6 services internally [RFC1687]. 102 End-user sites that currently use IPv4 services internally come in 103 endless sizes and varieties. For example, a home network behind a 104 Network Address Translator (NAT) may consist of a single link 105 supporting a few laptops, printers etc. As a larger example, a small 106 business may consist of one or a few offices with several networks 107 connecting considerably larger numbers of computers, routers, 108 handheld devices, printers, faxes, etc. Moving further up the scale, 109 large banks, restaurants, major retailers, large corporations, etc. 110 may consist of hundreds or thousands of branches worldwide that are 111 tied together in a complex global enterprise network. Additional 112 examples include personal-area networks, mobile vehicular networks, 113 disaster relief networks, tactical military networks, and various 114 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 115 discussed in RANGERS[RFC6139]. 117 With the proliferation of IPv6 devices in the public Internet, 118 however, existing IPv4 sites will increasingly require a means for 119 enabling IPv6 services so that hosts within the site can communicate 120 with IPv6-only correspondents. Such services must be deployable with 121 minimal configuration, and in a fashion that will not cause 122 disruptions to existing IPv4 services. The Intra-Site Automatic 123 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 124 use service that sites can deploy in the near term to meet these 125 requirements. This document therefore provides operational guidance 126 for using ISATAP to enable IPv6 services within predominantly IPv4 127 sites while causing no disruptions to existing IPv4 services. 129 2. Enabling IPv6 Services using ISATAP 131 Many existing sites within the Internet predominantly use IPv4-based 132 services for their internal networking needs, but there is a growing 133 requirement for enabling IPv6 services to support communications with 134 IPv6-only correspondents. Smaller sites that wish to enable IPv6 135 typically arrange to obtain public IPv6 prefixes from an Internet 136 Service Provider (ISP), where the prefixes may be either purely 137 native or the near-native prefixes offered by 6rd [RFC5969]. Larger 138 sites typically obtain provider independent IPv6 prefixes from an 139 Internet registry and advertise the prefixes into the IPv6 routing 140 system on their own behalf, i.e., they act as an ISP unto themselves. 141 In either case, after obtaining IPv6 prefixes the site can 142 automatically enable IPv6 services internally by configuring ISATAP. 144 The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) 145 tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in- 146 IPv4 encapsulation [RFC4213]. The encapsulation format can further 147 use Differentiated Service (DS) [RFC2983] and Explicit Congestion 148 Notification (ECN) [RFC3168] mapping between the inner and outer IP 149 headers to ensure expected per-hop behavior within well-managed 150 sites. 152 The ISATAP service is based on three basic node types known as 153 advertising ISATAP routers, non-advertising ISATAP routers and ISATAP 154 hosts. Advertising ISATAP routers configure their site-facing ISATAP 155 interfaces as advertising router interfaces (see: [RFC4861], Section 156 6.2.2). Non-advertising ISATAP routers configure their site-facing 157 ISATAP interfaces as non-advertising router interfaces and obtain 158 IPv6 addresses/prefixes via autoconfiguration exchanges with 159 advertising ISATAP routers. Finally, ISATAP hosts configure their 160 site-facing ISATAP interfaces as simple host interfaces and also 161 coordinate their autoconfiguration operations with advertising ISATAP 162 routers. In this sense, advertising ISATAP routers are "servers" 163 while non-advertising ISATAP routers and ISATAP hosts are "clients" 164 in the service model. 166 Advertising ISATAP routers arrange to add their IPv4 address to the 167 Potential Router List (PRL) within the site name service. The name 168 service could be either the DNS or some other site-internal name 169 resolution system, but the PRL should be published in such a way that 170 ISATAP clients can resolve the name "isatap.domainname" for the 171 "domainname" suffix associated with their attached link. For 172 example, if the domainname suffix associated with an ISATAP client's 173 attached link is "example.com", then the name of the PRL for that 174 link attachment point is "isatap.example.com". Alternatively, if the 175 site name service is operating without a domainname suffix, then the 176 name of the PRL is simply "isatap". (In either case, however, site 177 administrators should ensure that the name resolution returns IPv4 178 addresses of advertising ISATAP routers that are topologically close 179 to each ISATAP client depending on their locations.) 181 After the PRL is published, ISATAP clients within the site will 182 automatically perform a standard IPv6 Neighbor Discovery Router 183 Solicitation (RS) / Router Advertisement (RA) exchange with 184 advertising ISATAP routers [RFC4861][RFC5214]. Each ISATAP client 185 can also test the round-trip delays to multiple advertising ISATAP 186 routers listed in the PRL during an initial exchange, and select 187 those routers with the smallest delays. Alternatively, site 188 administrators could include an IPv4 anycast address in the PRL and 189 assign the address to multiple advertising ISATAP routers. In that 190 case, IPv4 routing within the site would direct the ISATAP client to 191 the nearest advertising ISATAP router. 193 Following router discovery, ISATAP clients initiate Stateless Address 194 AutoConfiguration (SLAAC) [RFC4862][RFC5214], the Dynamic Host 195 Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or both. 197 3. SLAAC Services 199 Predominantly IPv4 sites can enable SLAAC services for ISATAP clients 200 that need to communicate with IPv6 correspondents. SLAAC services 201 are enabled using either the "shared" or "individual" prefix model. 202 In the shared prefix model, all advertising ISATAP routers advertise 203 a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the 204 site. In the individual prefix model, advertising ISATAP router 205 advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0: 206 2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within the site. 207 Note that combinations of the shared and individual prefix models are 208 also possible, in which some of the site's ISATAP routers advertise 209 shared prefixes and others advertise individual prefixes 211 The following sections discuss operational considerations for 212 enabling ISATAP SLAAC services within predominantly IPv4 sites. 214 3.1. Advertising ISATAP Router Behavior 216 Advertising ISATAP routers that support SLAAC services send RA 217 messages in response to RS messages received on an advertising ISATAP 218 interface. SLAAC services are enabled when advertising ISATAP 219 routers advertise non-link-local IPv6 prefixes in Prefix Information 220 Options (PIOs) with the A flag set to 1[RFC4861]. When there are 221 multiple advertising ISATAP routers, the routers can advertise a 222 shared IPv6 prefix or individual IPv6 prefixes. 224 3.2. Non-Advertising ISATAP Router Behavior 226 Non-advertising ISATAP routers that engage in SLAAC behave the same 227 as for hosts (see below). 229 3.3. ISATAP Host Behavior 231 ISATAP hosts resolve the PRL and send RS messages to obtain RA 232 messages from an advertising ISATAP router. When the host receives 233 RA messages, it uses SLAAC to configure IPv6 addresses from any 234 advertised prefixes with the A flag set to 1 as specified in 235 [RFC4862][RFC5214] then assigns the addresses to the ISATAP 236 interface. The host also assigns any of the advertised prefixes with 237 the L flag set to 1 to the ISATAP interface. 239 Any IPv6 addresses configured in this fashion and assigned to an 240 ISATAP interface are known as ISATAP addresses. 242 3.4. Reference Operational Scenario - Shared Prefix Model 244 Figure 1 depicts a reference ISATAP network topology for allowing 245 hosts within a predominantly IPv4 site to configure ISATAP services 246 using SLAAC with the shared prefix model. The scenario shows two 247 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 248 and an ordinary IPv6 host ('E') outside of the site in a typical 249 deployment configuration. In this model, routers 'A' and 'B' both 250 advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 251 routing system, and also advertise the prefix to ISATAP clients 252 within the site for SLAAC purposes. 254 .-(::::::::) 2001:db8:1::1 255 .-(::: IPv6 :::)-. +-------------+ 256 (:::: Internet ::::) | IPv6 Host E | 257 `-(::::::::::::)-' +-------------+ 258 `-(::::::)-' 259 +------------+ +------------+ 260 | Router A |---.---| Router B |. 261 ,| (isatap) | | (isatap) | `\ 262 . | 192.0.2.1 | | 192.0.2.1 | \ 263 / +------------+ +------------+ \ 264 : fe80::*:192.0.2.17 fe80::*:192.0.2.33 : 265 \ 2001:db8::/64 2001:db8::/64 / 266 : : 267 : : 268 +- IPv4 Site -+ 269 ; (PRL: 192.0.2.1) : 270 | ; 271 : -+-' 272 `-. .) 273 \ _) 274 `-----+--------)----+'----' 275 fe80::*:192.0.2.18 fe80::*:192.0.2.34 276 2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34 277 +--------------+ +--------------+ 278 | (isatap) | | (isatap) | 279 | Host C | | Host D | 280 +--------------+ +--------------+ 282 (* == "5efe") 284 Figure 1: Reference ISATAP Network Topology using Shared Prefix Model 286 With reference to Figure 1, advertising ISATAP routers 'A' and 'B' 287 within the IPv4 site connect to the IPv6 Internet either directly or 288 via a companion gateway (e.g., as shown in Figure 3). The routers 289 advertise the shared prefix 2001:db8::/64 into the IPv6 Internet 290 routing system either as a singleton /64 or as part of a shorter 291 aggregated IPv6 prefix if the routing system will not accept prefixes 292 as long as a /64. For the purpose of this example, we also assume 293 that the IPv4 site is configured within multiple IPv4 subnets - each 294 with an IPv4 prefix length of /28. 296 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 297 anycast address 192.0.2.1, e.g., on a loopback interface, and the 298 site administrator places the single IPv4 address 192.0.2.1 in the 299 PRL for the site. 'A' and 'B' then both advertise the anycast 300 address/prefix into the site's IPv4 routing system so that ISATAP 301 clients can locate the router that is topologically closest. 303 Advertising ISATAP router 'A' next configures a site-interior IPv4 304 interface with address 192.0.2.17 and netmask /28, then configures an 305 advertising ISATAP router interface with link-local ISATAP address 306 fe80::5efe:192.0.2.17 over the IPv4 interface. In the same fashion, 307 'B' configures a site-interior IPv4 interface with address 308 192.0.2.33/28, then configures its advertising ISATAP router 309 interface with link-local ISATAP address fe80::5efe:192.0.2.33. 311 ISATAP host 'C' connects to the site via an IPv4 interface with 312 address 192.0.2.18/28, and also configures an ISATAP host interface 313 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 314 interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4 315 encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4 316 routing will direct it to the closest of either 'A' or 'B'. Assuming 317 'A' is closest, 'C' receives an RA from 'A' then configures a default 318 IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP 319 interface and processes the IPv6 prefix 2001:db8:0:1::/64 advertised 320 in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to 321 automatically configure the ISATAP address 2001:db8:0:1::5efe: 322 192.0.2.18 and assigns the address to the ISATAP interface. If the L 323 flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 to the 324 ISATAP interface. 326 In the same fashion, ISATAP host 'D' configures its IPv4 interface 327 with address 192.0.2.34/28 and configures its ISATAP interface with 328 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 329 an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to 330 autoconfigure the ISATAP address 2001:db8::5efe:192.0.2.34 and a 331 default IPv6 route with next-hop address fe80::5efe:192.0.2.33. 332 Finally, IPv6 host 'E' connects to an IPv6 network outside of the 333 site. 'E' configures its IPv6 interface in a manner specific to its 334 attached IPv6 link, and autoconfigures the IPv6 address 335 2001:db8:1::1. 337 Following this autoconfiguration, when host 'C' inside the site has 338 an IPv6 packet to send to host 'E' outside the site, it prepares the 339 packet with source address 2001:db8::5efe:192.0.2.18 and destination 340 address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to 341 forward the packet to the link-local address of its default router 342 'A' (i.e., fe80::5efe:192.0.2.17). 'A' in turn decapsulates the 343 packet and forwards it into the public IPv6 Internet where it will be 344 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 345 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 346 send IPv6 packets to IPv6 Internet hosts such as 'E'. 348 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 349 inside the site, the IPv6 routing system may direct the packet to 350 either of 'A' or 'B'. If the site is not partitioned internally, the 351 router that receives the packet can use ISATAP to statelessly forward 352 the packet directly to 'C'. If the site may be partitioned 353 internally, however, the packet must first be forwarded to 'C's 354 serving router based on IPv6 routing information. This implies that, 355 in a partitioned site, the advertising ISATAP routers must connect 356 within a full or partial mesh of IPv6 links, and must either run a 357 dynamic IPv6 routing protocol or configure static routes so that 358 incoming IPv6 packets can be forwarded to the correct serving router. 360 In this example, 'A' can configure the IPv6 route 2001:db8::5efe: 361 192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in 362 the mesh network as the next hop, and 'B' can configure the IPv6 363 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next 364 hop toward 'A' as the next hop. (Notice that the /124 prefixes 365 properly cover the /28 prefix of the IPv4 address that is embedded 366 within the IPv6 ISATAP address.) In that case, when 'A' receives a 367 packet from the IPv6 Internet with destination address 2001:db8:: 368 5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 369 mesh link. 'B' in turn uses ISATAP to forward the packet into the 370 site, where IPv4 routing will direct it to 'D'. In the same fashion, 371 when 'B' receives a packet from the IPv6 Internet with destination 372 address 2001:db8::5efe:192.0.2.18, it first forwards the packet 373 toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward 374 the packet into the site, where IPv4 routing will direct it to 'C'. 376 Finally, when host 'C' inside the site connects to host 'D' inside 377 the site, it has the option of using the native IPv4 service or the 378 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 379 assurance that IPv4 services between the two hosts are available, the 380 hosts would be better served to continue to use legacy IPv4 services 381 in order to avoid encapsulation overhead and to avoid any IPv4 382 protocol-41 filtering middleboxes that may be in the path. If 'C' 383 and 'D' may be in different IPv4 network partitions, however, IPv6- 384 in-IPv4 encapsulation should be used with one or both of routers 'A' 385 and 'B' serving as intermediate gateways. 387 3.5. Reference Operational Scenario - Individual Prefix Model 389 Figure 2 depicts a reference ISATAP network topology for allowing 390 hosts within a predominantly IPv4 site to configure ISATAP services 391 using SLAAC with the individual prefix model. The scenario shows two 392 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 393 and an ordinary IPv6 host ('E') outside of the site in a typical 394 deployment configuration. In the figure, ISATAP routers 'A' and 'B' 395 both advertise different prefixes taken from the aggregated prefix 396 2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B' 397 advertising 2001:db8:0:2::/64. 399 .-(::::::::) 2001:db8:1::1 400 .-(::: IPv6 :::)-. +-------------+ 401 (:::: Internet ::::) | IPv6 Host E | 402 `-(::::::::::::)-' +-------------+ 403 `-(::::::)-' 404 +------------+ +------------+ 405 | Router A |---.---| Router B |. 406 ,| (isatap) | | (isatap) | `\ 407 . | 192.0.2.1 | | 192.0.2.1 | \ 408 / +------------+ +------------+ \ 409 : fe80::*:192.0.2.17 fe80::*:192.0.2.33 : 410 \ 2001:db8:0:1::/64 2001:db8:0:2::/64 / 411 : : 412 : : 413 +- IPv4 Site -+ 414 ; (PRL: 192.0.2.1) : 415 | ; 416 : -+-' 417 `-. .) 418 \ _) 419 `-----+--------)----+'----' 420 fe80::*:192.0.2.18 fe80::*:192.0.2.34 421 2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34 422 +--------------+ +--------------+ 423 | (isatap) | | (isatap) | 424 | Host C | | Host D | 425 +--------------+ +--------------+ 427 (* == "5efe") 429 Figure 2: Reference ISATAP Network Topology using Individual Prefix 430 Model 432 With reference to Figure 2, advertising ISATAP routers 'A' and 'B' 433 within the IPv4 site connect to the IPv6 Internet either directly or 434 via a companion gateway (e.g., as shown in Figure 3). Router 'A' 435 advertises the individual prefix 2001:db8:0:1::/64 into the IPv6 436 Internet routing system, and router 'B' advertises the individual 437 prefix 2001:db8:0:2::/64. The routers could instead both advertise a 438 shorter shared prefix such as 2001:db8::/48 into the IPv6 routing 439 system, but in that case they would need to configure a mesh of IPv6 440 links between themselves in the same fashion as described for the 441 shared prefix model in Section 3.4. For the purpose of this example, 442 we also assume that the IPv4 site is configured within multiple IPv4 443 subnets - each with an IPv4 prefix length of /28. 445 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 446 anycast address 192.0.2.1, e.g., on a loopback interface, and the 447 site administrator places the single IPv4 address 192.0.2.1 in the 448 PRL for the site. 'A' and 'B' then both advertise the anycast 449 address/prefix into the site's IPv4 routing system so that ISATAP 450 clients can locate the router that is topologically closest. 452 Advertising ISATAP router 'A' next configures a site-interior IPv4 453 interface with address 192.0.2.17/28, then configures an advertising 454 ISATAP router interface with link-local ISATAP address fe80::5efe: 455 192.0.2.17 over the IPv4 interface. In the same fashion, 'B' 456 configures the IPv4 interface address 192.0.2.33/28, then configures 457 its advertising ISATAP router interface with link-local ISATAP 458 address fe80::5efe:192.0.2.33. 460 ISATAP host 'C' connects to the site via an IPv4 interface with 461 address 192.0.2.18/28, and also configures an ISATAP host interface 462 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 463 interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4 464 encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4 465 routing will direct it to the closest of either 'A' or 'B'. Assuming 466 'A' is closest, 'C' receives an RA from 'A' then configures a default 467 IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP 468 interface and processes the IPv6 prefix 2001:db8:0:1::/64 advertised 469 in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to 470 automatically configure the ISATAP address 2001:db8:0:1::5efe: 471 192.0.2.18 and assigns the address to the ISATAP interface. If the L 472 flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 to the 473 ISATAP interface. 475 In the same fashion, ISATAP host 'D' configures its IPv4 interface 476 with address 192.0.2.34/28 and configures its ISATAP interface with 477 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 478 an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to 479 autoconfigure the ISATAP address 2001:db8:0:2::5efe:192.0.2.34 and a 480 default IPv6 route with next-hop address fe80::5efe:192.0.2.33. 481 Finally, IPv6 host 'E' connects to an IPv6 network outside of the 482 site. 'E' configures its IPv6 interface in a manner specific to its 483 attached IPv6 link, and autoconfigures the IPv6 address 484 2001:db8:1::1. 486 Following this autoconfiguration, when host 'C' inside the site has 487 an IPv6 packet to send to host 'E' outside the site, it prepares the 488 packet with source address 2001:db8:0:1::5efe:192.0.2.18 and 489 destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 490 encapsulation to forward the packet to the link-local ISATAP address 491 of 'A' (fe80::5efe:192.0.2.17), where 'A' in turn decapsulates the 492 packet and forwards it into the public IPv6 Internet where it will be 493 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 494 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 495 send IPv6 packets to IPv6 Internet hosts such as 'E'. 497 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 498 inside the site, the IPv6 routing system will direct the packet to 499 'A' since 'A' advertises the individual prefix that matches 'C's 500 destination address. 'A' can then use ISATAP to statelessly forward 501 the packet directly to 'C'. If 'A' and 'B' both advertise the shared 502 shorter prefix 2001:db8::/48 into the IPv6 routing system, however 503 packets coming from 'E' may be directed to either 'A' or 'B'. In 504 that case, the advertising ISATAP routers must connect within a full 505 or partial mesh of IPv6 links the same as for the shared prefix 506 model, and must either run a dynamic IPv6 routing protocol or 507 configure static routes so that incoming IPv6 packets can be 508 forwarded to the correct serving router. 510 In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 511 with the IPv6 address of the next hop toward 'B' in the mesh network 512 as the next hop, and 'B' can configure the IPv6 route 2001:db8: 513 0.1::/64 with the IPv6 address of the next hop toward 'A' as the next 514 hop. Then, when 'A' receives a packet from the IPv6 Internet with 515 destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards 516 the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses 517 ISATAP to forward the packet into the site, where IPv4 routing will 518 direct it to 'D'. In the same fashion, when 'B' receives a packet 519 from the IPv6 Internet with destination address 2001:db8:0:1::5efe: 520 192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh 521 link. 'A' then uses ISATAP to forward the packet into the site, 522 where IPv4 routing will direct it to 'C'. 524 Finally, when host 'C' inside the site connects to host 'D' inside 525 the site, it has the option of using the native IPv4 service or the 526 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 527 assurance that IPv4 services between the two hosts are available, the 528 hosts would be better served to continue to use legacy IPv4 services 529 in order to avoid encapsulation overhead and to avoid any IPv4 530 protocol-41 filtering middleboxes that may be in the path. If 'C' 531 and 'D' may be in different IPv4 network partitions, however, IPv6- 532 in-IPv4 encapsulation should be used with one or both of routers 'A' 533 and 'B' serving as intermediate gateways. 535 3.6. SLAAC Site Administration Guidance 537 In common practice, firewalls, gateways and packet filtering devices 538 of various forms are often deployed in order to divide the site into 539 separate partitions. In both the shared and individual prefix models 540 described above, the entire site can be represented by the aggregate 541 IPv6 prefix assigned to the site, while each site partition can be 542 represented by "sliver" IPv6 prefixes taken from the aggregate. In 543 order to provide a simple service that does not interact poorly with 544 the site topology, site administrators should therefore institute an 545 address plan to align IPv6 sliver prefixes with IPv4 site partition 546 boundaries. 548 For example, in the shared prefix model in Section 3.4, the aggregate 549 prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe: 550 192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe: 551 192.0.2.32/124, etc. In the individual prefix model in Section 3.5, 552 the aggregate prefix is 2001:db8::/48 and the sliver prefixes are 553 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc. 555 When individual prefixes are used, site administrators can configure 556 advertising ISATAP routers to advertise different individual (sliver) 557 prefixes to different sets of clients, e.g., based on the client's 558 IPv4 subnet prefix. When a shared prefix is used, the site 559 administrator could instead configure the ISATAP routers to advertise 560 the shared (aggregate) prefix with L=0 so that clients will not 561 consider any IPv6 addresses derived from the prefix as on-link. 563 Site administrators can then institute a policy that prefers native 564 IPv4 addresses over ISATAP addresses for communications between 565 clients covered by the same sliver prefix. Site administrators 566 implement this policy by configuring address selection policy rules 567 [RFC3484] in each ISATAP client in order to give preference to IPv4 568 destination addresses over destination addresses derived from one of 569 the client's IPv6 sliver prefixes. 571 For example, each ISATAP client associated with the sliver prefix 572 2001:db8::5efe:192.0.2.64/124 can add the prefix to its address 573 selection policy table with a lower precedence than the prefix 574 ::ffff:0:0/96. In this way, IPv4 addresses are preferred over IPv6 575 addresses from within the same sliver. The prefix could be added to 576 each ISATAP client either manually, or through an automated service 577 such as a DHCP option [I-D.ietf-6man-addr-select-opt]. In this way, 578 clients will use IPv4 communications to reach correspondents within 579 the same IPv4 site partition, and will use IPv6 communications to 580 reach correspondents in other partitions and/or outside of the site. 582 3.7. Loop Avoidance 584 In sites that provide IPv6 services through ISATAP with SLAAC as 585 described in this section, advertising ISATAP routers must take 586 operational precautions to avoid routing loops. For example, with 587 reference to Figure 2 an IPv6 packet that enters the site via 588 advertising ISATAP router 'A' must not be allowed to exit the site 589 via advertising ISATAP router 'B' based on an invalid SLAAC address. 591 As a simple mitigation, each advertising ISATAP router should drop 592 any packets coming from the IPv6 Internet that would be forwarded 593 back to the Internet via another advertising router. Additionally, 594 each advertising ISATAP router should drop any encapsulated packets 595 received from another advertising router that would be forwarded to 596 the IPv6 Internet. (Note that IPv6 packets with link-local ISATAP 597 addresses are excluded from these checks, since they cannot be 598 forwarded by an IPv6 router and may be necessary for router-to-router 599 coordinations.) This corresponds to the mitigation documented in 600 Section 3.2.3 of [I-D.ietf-v6ops-tunnel-loops], but other mitigations 601 specified in that document can also be employed. 603 Again with reference to Figure 2, when 'A' receives a packet coming 604 from the IPv6 Internet with destination address 2001:db8:1::5efe: 605 192.0.2.2, it drops the packet since the IPv4 address 192.0.2.2 606 corresponds to advertising ISATAP router 'B'. Similarly, when 'B' 607 receives a packet coming from the tunnel with an IPv6 destination 608 address that would cause the packet to be forwarded back out to the 609 IPv6 Internet and with an IPv4 source address 192.0.2.1, it drops the 610 packet since 192.0.2.1 corresponds to advertising ISATAP router 'A'. 612 4. DHCPv6 Services 614 Whether or not advertising ISATAP routers make stateless IPv6 615 services available using SLAAC, they can also provide managed IPv6 616 services to ISATAP clients (i.e., both hosts and non-advertising 617 ISATAP routers) using the Dynamic Host Configuration Protocol for 618 IPv6 (DHCPv6). Any addresses/prefixes obtained via DHCPv6 are 619 distinct from any IPv6 prefixes advertised on the ISATAP interface 620 for SLAAC purposes, however. In this way, DHCPv6 addresses/prefixes 621 are reached by viewing the ISATAP tunnel interface as a "transit" 622 rather than viewing it as an ordinary IPv6 host interface. We refer 623 to this as the "no prefix" model. 625 ISATAP nodes employ the source address verification checks specified 626 in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of 627 packets received on an ISATAP interface. In order to accommodate 628 direct communications with hosts and non-advertising ISATAP routers 629 that use DHCPv6, ISATAP nodes that support route optimization must 630 employ an additional source address verification check. Namely, the 631 node also considers the outer IPv4 source address correct for the 632 inner IPv6 source address if: 634 o a forwarding table entry exists that lists the packet's IPv4 635 source address as the link-layer address corresponding to the 636 inner IPv6 source address via the ISATAP interface. 638 The following sections discuss operational considerations for 639 enabling ISATAP DHCPv6 services within predominantly IPv4 sites. 641 4.1. Advertising ISATAP Router Behavior 643 Advertising ISATAP routers that support DHCPv6 services send RA 644 messages in response to RS messages received on an advertising ISATAP 645 interface. Advertising ISATAP routers also configure either a DHCPv6 646 relay or server function to service DHCPv6 requests received from 647 ISATAP clients. 649 4.2. Non-Advertising ISATAP Router Behavior 651 Non-advertising ISATAP routers can acquire IPv6 prefixes, e.g., 652 through the use of DHCPv6 Prefix Delegation [RFC3633] via an 653 advertising router in the same fashion as described for host-based 654 DHCPv6 stateful address autoconfiguration in Section 4.3. The 655 advertising router in turn maintains IPv6 forwarding table entries 656 that list the IPv4 address of the non-advertising router as the link- 657 layer address of the next hop toward the delegated IPv6 prefixes. 659 In many use case scenarios (e.g., small enterprise networks, MANETs, 660 etc.), advertising and non-advertising ISATAP routers can engage in a 661 proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) 662 over their ISATAP interfaces so that IPv6 routing/forwarding tables 663 can be populated and standard IPv6 forwarding between ISATAP routers 664 can be used. In other scenarios (e.g., large enterprise networks, 665 highly mobile MANETs, etc.), this might be impractical dues to 666 scaling issues. When a proactive dynamic routing protocol cannot be 667 used, non-advertising ISATAP routers send RS messages to obtain RA 668 messages from an advertising ISATAP router, i.e., they act as "hosts" 669 on their non-advertising ISATAP interfaces. 671 After the non-advertising ISATAP router acquires IPv6 prefixes, it 672 can sub-delegate them to routers and links within its attached IPv6 673 edge networks, then can forward any outbound IPv6 packets coming from 674 its edge networks via other ISATAP nodes on the link. 676 4.3. ISATAP Host Behavior 678 ISATAP hosts resolve the PRL and send RS messages to obtain RA 679 messages from an advertising ISATAP router. Whether or not IPv6 680 prefixes for SLAAC are advertised, the host can acquire IPv6 681 addresses, e.g., through the use of DHCPv6 stateful address 682 autoconfiguration [RFC3315]. To acquire addresses, the host performs 683 standard DHCPv6 exchanges while mapping the IPv6 684 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 685 the IPv4 address of an advertising ISATAP router. 687 After the host receives IPv6 addresses, it assigns them to its ISATAP 688 interface and forwards any of its outbound IPv6 packets via the 689 advertising router as a default router. The advertising router in 690 turn maintains IPv6 forwarding table entries that list the IPv4 691 address of the host as the link-layer address of the delegated IPv6 692 addresses. Note that IPv6 addresses acquired from DHCPv6 therefore 693 need not be ISATAP addresses, i.e., even though the addresses are 694 assigned to the ISATAP interface. 696 4.4. Reference Operational Scenario - No Prefix Model 698 Figure 3 depicts a reference ISATAP network topology that uses 699 DHCPv6. The scenario shows two advertising ISATAP routers ('A', 700 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host 701 ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical 702 deployment configuration: 704 .-(::::::::) 2001:db8:3::1 705 .-(::: IPv6 :::)-. +-------------+ 706 (:::: Internet ::::) | IPv6 Host H | 707 `-(::::::::::::)-' +-------------+ 708 `-(::::::)-' 709 ,~~~~~~~~~~~~~~~~~, 710 ,----|companion gateway|--. 711 / '~~~~~~~~~~~~~~~~~' : 712 / |. 713 ,-' `. 714 ; +------------+ +------------+ ) 715 : | Router A | | Router B | / 716 : | (isatap) | | (isatap) | : fe80::*192.0.2.6 717 : | 192.0.2.1 | | 192.0.2.1 | ; 2001:db8:2::1 718 + +------------+ +------------+ \ +--------------+ 719 fe80::*:192.0.2.2 fe80::*:192.0.2.3 | (isatap) | 720 | ; | Host G | 721 : IPv4 Site -+-' +--------------+ 722 `-. (PRL: 192.0.2.1) .) 723 \ _) 724 `-----+--------)----+'----' 725 fe80::*:192.0.2.4 fe80::*:192.0.2.5 .-. 726 +--------------+ +--------------+ ,-( _)-. 727 | (isatap) | | (isatap) | .-(_ IPv6 )-. 728 | Router C | | Router E |--(__Edge Network ) 729 +--------------+ +--------------+ `-(______)-' 730 2001:db8:0::/48 2001:db8:1::/48 | 731 | 2001:db8:1::1 732 .-. +-------------+ 733 ,-( _)-. 2001:db8::1 | IPv6 Host F | 734 .-(_ IPv6 )-. +-------------+ +-------------+ 735 (__Edge Network )--| IPv6 Host D | 736 `-(______)-' +-------------+ 738 (* == "5efe") 740 Figure 3: Reference ISATAP Network Topology using No Prefix Model 742 In Figure 3, advertising ISATAP routers 'A' and 'B' within the IPv4 743 site connect to the IPv6 Internet via a companion gateway. (Note 744 that the routers may instead connect to the IPv6 Internet directly as 745 shown in Figure 1. For the purpose of this example, we also assume 746 that the IPv4 site is configured within a single IPv4 subnet. 748 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 749 anycast address 192.0.2.1, e.g., on a loopback interface, and the 750 site administrator places the single IPv4 address 192.0.2.1 in the 751 PRL for the site. 'A' and 'B' then both advertise the anycast 752 address/prefix into the site's IPv4 routing system so that ISATAP 753 clients can locate the router that is topologically closest. 755 Advertising ISATAP router 'A' next configures a site-interior IPv4 756 interface with address 192.0.2.2, then configures an advertising 757 ISATAP router interface with link-local ISATAP address fe80::5efe: 758 192.0.2.2 over the IPv4 interface. In the same fashion, 'B' 759 configures the IPv4 interface address 192.0.2.3, then configures its 760 advertising ISATAP router interface with link-local ISATAP address 761 fe80::5efe:192.0.2.3. 763 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 764 networks and also connects to the site via an IPv4 interface with 765 address 192.0.2.4, but it does not advertise the site's IPv4 anycast 766 address/prefix. 'C' next configures a non-advertising ISATAP router 767 interface with link-local ISATAP address fe80::5efe:192.0.2.4, then 768 discovers router 'A' via an IPv6-in-IPv4 encapsulated RS/RA exchange. 769 'C' next receives the IPv6 prefix 2001:db8::/48 through a DHCPv6 770 prefix delegation exchange via 'A', then engages in an IPv6 routing 771 protocol over its ISATAP interface and announces the delegated IPv6 772 prefix. 'C' finally sub-delegates the prefix to its attached edge 773 networks, where IPv6 host 'D' autoconfigures the address 2001:db8::1. 775 Non-advertising ISATAP router 'E' connects to the site, configures 776 its ISATAP interface, performs an RS/RA exchange, receives a DHCPv6 777 prefix delegation, and engages in the IPv6 routing protocol the same 778 as for 'C'. In particular, 'E' configures the IPv4 address 192.0.2.5 779 and the link-local ISATAP address fe80::5efe:192.0.2.5. 'E' then 780 receives the delegated IPv6 prefix 2001:db8:1::/48 and sub-delegates 781 the prefix to its attached edge networks, where IPv6 host 'F' 782 autoconfigures IPv6 address 2001:db8:1::1. 784 ISATAP host 'G' connects to the site via an IPv4 interface with 785 address 192.0.2.6, and also configures an ISATAP host interface with 786 link-local ISATAP address fe80::5efe:192.0.2.6 over the IPv4 787 interface. 'G' next performs an anycast RS/RA exchange to discover 788 'B" and configure a default IPv6 route with next-hop address fe80:: 789 5efe:192.0.2.3. 'G' then receives the IPv6 address 2001:db8:2::1 790 from a DHCPv6 address configuration exchange via 'B'; it then assigns 791 the address to the ISATAP interface but does not assign a non-link- 792 local IPv6 prefix to the interface. 794 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 795 ISATAP domain. 'H' configures its IPv6 interface in a manner 796 specific to its attached IPv6 link, and autoconfigures the IPv6 797 address 2001:db8:3::1. 799 Following this autoconfiguration, when host 'D' has an IPv6 packet to 800 send to host 'F', it prepares the packet with source address 2001: 801 db8::1 and destination address 2001:db8:1::1, then sends the packet 802 into the edge network where IPv6 forwarding will eventually convey it 803 to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to forward 804 the packet to router 'E', since it has discovered a route to 2001: 805 db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP 806 interface. Router 'E' finally sends the packet into the edge network 807 where IPv6 forwarding will eventually convey it to host 'F'. 809 In a second scenario, when 'D' has a packet to send to ISATAP host 810 'G', it prepares the packet with source address 2001:db8::1 and 811 destination address 2001:db8:2::1, then sends the packet into the 812 edge network where it will eventually be forwarded to router 'C' the 813 same as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward 814 the packet to router 'A' (i.e., 'C's default router), which in turn 815 forwards the packet to 'G'. Note that this operation entails two 816 hops across the ISATAP link (i.e., one from 'C' to 'A', and a second 817 from 'A' to 'G'). If 'G' also participates in the dynamic IPv6 818 routing protocol, however, 'C' could instead forward the packet 819 directly to 'G' without involving 'A'. 821 In a third scenario, when 'D' has a packet to send to host 'H' in the 822 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 823 then forwards the packet to 'A', which forwards the packet into the 824 IPv6 Internet. 826 In a final scenario, when 'G' has a packet to send to host 'H' in the 827 IPv6 Internet, the packet is forwarded directly to 'B', which 828 forwards the packet into the IPv6 Internet. 830 4.5. On-Demand Dynamic Routing for DHCP 832 With respect to the reference operational scenarios depicted in 833 Figure 3, there may be use cases in which a proactive dynamic IPv6 834 routing protocol cannot be used. For example, in large enterprise 835 network deployments it would be impractical for all ISATAP routers to 836 engage in a common routing protocol instance due to scaling 837 considerations. 839 In those cases, an on-demand routing capability can be enabled in 840 which ISATAP nodes send initial packets via an advertising ISATAP 841 router and receive redirection messages back. For example, when a 842 non-advertising ISATAP router 'C' has a packet to send to a host 843 located behind non-advertising ISATAP router 'E', it can send the 844 initial packets via advertising router 'A' which will return 845 redirection messages to inform 'C' that 'E' is a better first hop. 846 Protocol details for this redirection procedure (including a means 847 for detecting whether the direct path is usable) are specified in 849 [I-D.templin-aero]. 851 4.6. Loop Avoidance 853 In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6 854 prefixes are assigned to ISATAP router interfaces. Therefore, an 855 ISATAP router cannot mistake another router for an ISATAP host due to 856 an address that matches an on-link prefix. This corresponds to the 857 mitigation documented in Section 3.2.4 of 858 [I-D.ietf-v6ops-tunnel-loops]. 860 Any routing loops introduced in the DHCPv6 scenario would therefore 861 be due to a misconfiguration in IPv6 routing the same as for any IPv6 862 router, and hence are out of scope for this document. 864 5. Scaling Considerations 866 Sections 3 and 4 depict ISATAP network topologies with only two 867 advertising ISATAP routers within the site. In order to support 868 larger numbers of ISATAP clients (and/or multiple site partitions), 869 the site can deploy more advertising ISATAP routers to support load 870 balancing and generally shortest-path routing. 872 Such an arrangement requires that the advertising ISATAP routers 873 participate in an IPv6 routing protocol instance so that IPv6 874 addresses/prefixes can be mapped to the correct ISATAP router. The 875 routing protocol instance can be configured as either a full mesh 876 topology involving all advertising ISATAP routers, or as a partial 877 mesh topology with each advertising ISATAP router associating with 878 one or more companion gateways. Each such companion gateway would in 879 turn participate in a full mesh between all companion gateways. 881 6. Site Renumbering Considerations 883 Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients 884 within the site via DHCPv6 and/or SLAAC. If the site subsequently 885 reconnects to a different ISP, however, the site must renumber to use 886 addresses derived from the new IPv6 prefixes 887 [RFC1900][RFC4192][RFC5887]. 889 For IPv6 services provided by SLAAC, site renumbering in the event of 890 a change in an ISP-served IPv6 prefix entails a simple renumbering of 891 IPv6 addresses and/or prefixes that are assigned to the ISATAP 892 interfaces of clients within the site. In some cases, filtering 893 rules (e.g., within site border firewall filtering tables) may also 894 require renumbering, but this operation can be automated and limited 895 to only one or a few administrative "touch points". 897 In order to renumber the ISATAP interfaces of clients within the site 898 using SLAAC, advertising ISATAP routers need only schedule the 899 services offered by the old ISP for deprecation and begin to 900 advertise the IPv6 prefixes provided by the new ISP. ISATAP client 901 interface address lifetimes will eventually expire, and the host will 902 renumber its interfaces with addresses derived from the new prefixes. 903 ISATAP clients should also eventually remove any deprecated SLAAC 904 prefixes from their address selection policy tables, but this action 905 is not time-critical. 907 Finally, site renumbering in the event of a change in an ISP-served 908 IPv6 prefix further entails locating and rewriting all IPv6 addresses 909 in naming services, databases, configuration files, packet filtering 910 rules, documentation, etc. If the site has published the IPv6 911 addresses of any site-internal nodes within the public Internet DNS 912 system, then the corresponding resource records will also need to be 913 updated during the renumbering operation. This can be accomplished 914 via secure dynamic updates to the DNS. 916 7. Path MTU Considerations 918 IPv6-in-IPv4 encapsulation overhead effectively reduces the size of 919 IPv6 packets that can traverse the tunnel in relation to the actual 920 Maximum Transmission Unit (MTU) of the underlying IPv4 network path 921 between the encapsulator and decapsulator. Two methods for 922 accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels 923 (i.e., the static and dynamic methods) are documented in Section 3.2 924 of [RFC4213]. 926 The static method places a "safe" upper bound on the size of IPv6 927 packets permitted to enter the tunnel, however the method can be 928 overly conservative when larger IPv4 path MTUs are available. The 929 dynamic method can accommodate much larger IPv6 packet sizes in some 930 cases, but can fail silently if the underlying IPv4 network path does 931 not return the necessary error messages. 933 This document notes that sites that include well-managed IPv4 links, 934 routers and other network middleboxes are candidates for use of the 935 dynamic MTU determination method, which may provide for a better 936 operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. 937 The dynamic MTU determination method can potentially also present a 938 larger MTU to IPv6 correspondents outside of the site, since IPv6 939 path MTU discovery is considered robust even over the wide area in 940 the public IPv6 Internet. 942 8. Anycast Considerations 944 When an advertising ISATAP router configures an IPv4 anycast address, 945 and site administrators place the address in the PRL, the router uses 946 the anycast address as the IPv4 source address for all IPv6-in-IPv4 947 encapsulated packets it sends. However, the router must also derive 948 its ISATAP link-local addresses from an IPv4 unicast address assigned 949 to an underlying IPv4 interface instead of from the anycast address. 951 For example, if an advertising ISATAP router configures the IPv4 952 anycast address 192.0.2.1 and also configures an ordinary IPv4 953 interface with IPv4 unicast address 192.0.2.91, the router must 954 configure the ISATAP link-local address fe80::5efe:192.0.2.91 and use 955 this address as the IPv6 source / destination address in link-local 956 messages it exchanges with other ISATAP nodes. 958 This arrangement is necessary so that ISATAP clients can 959 unambiguously differentiate advertising ISATAP routers. Furthermore, 960 since the IPv4 anycast source address is a member of the PRL, ISATAP 961 clients will accept any messages coming from the advertising router 962 even though the IPv4 source address does not match the IPv4 address 963 embedded in the IPv6 source address. 965 9. Alternative Approaches 967 [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in 968 enterprise networks. The ISATAP approach provides a more flexible 969 and broadly-applicable alternative, and with fewer administrative 970 touch points. 972 The tunnel broker service [RFC3053] uses point-to-point tunnels that 973 require end users to establish an explicit administrative 974 configuration of the tunnel far end, which may be outside of the 975 administrative boundaries of the site. 977 6to4 [RFC3056] and Teredo [RFC4380] provide "last resort" unmanaged 978 automatic tunneling services when no other means for IPv6 979 connectivity is available. These services are given lower priority 980 when the ISATAP managed service and/or native IPv6 services are 981 enabled. 983 IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] 984 are a tribute to those in all walks of life who serve with dignity 985 and honor for the benefit of others. 987 10. IANA Considerations 989 This document has no IANA considerations. 991 11. Security Considerations 993 In addition to the security considerations documented in [RFC5214], 994 sites that use ISATAP should take care to ensure that no routing 995 loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security 996 concerns with IP tunneling are documented in [RFC6169]. 998 12. Acknowledgments 1000 The following are acknowledged for their insights that helped shape 1001 this work: Fred Baker, Brian Carpenter, Thomas Henderson, Philip 1002 Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, Gabi Nakibly, Hemant 1003 Singh, Mark Smith, Ole Troan, Gunter Van de Velde, ... 1005 13. References 1007 13.1. Normative References 1009 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1010 E. Lear, "Address Allocation for Private Internets", 1011 BCP 5, RFC 1918, February 1996. 1013 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1014 and M. Carney, "Dynamic Host Configuration Protocol for 1015 IPv6 (DHCPv6)", RFC 3315, July 2003. 1017 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1018 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1019 December 2003. 1021 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1022 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1024 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1025 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1026 September 2007. 1028 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1029 Address Autoconfiguration", RFC 4862, September 2007. 1031 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1032 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1033 March 2008. 1035 13.2. Informative References 1037 [I-D.ietf-6man-addr-select-opt] 1038 Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing 1039 Address Selection Policy using DHCPv6", 1040 draft-ietf-6man-addr-select-opt-00 (work in progress), 1041 December 2010. 1043 [I-D.ietf-v6ops-tunnel-loops] 1044 Nakibly, G. and F. Templin, "Routing Loop Attack using 1045 IPv6 Automatic Tunnels: Problem Statement and Proposed 1046 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 1047 progress), May 2011. 1049 [I-D.templin-aero] 1050 Templin, F., "Asymmetric Extended Route Optimization 1051 (AERO)", draft-templin-aero-00 (work in progress), 1052 March 2011. 1054 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 1055 RFC 1687, August 1994. 1057 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 1058 RFC 1900, February 1996. 1060 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1061 over Non-Broadcast Multiple Access (NBMA) networks", 1062 RFC 2491, January 1999. 1064 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1065 Domains without Explicit Tunnels", RFC 2529, March 1999. 1067 [RFC2983] Black, D., "Differentiated Services and Tunnels", 1068 RFC 2983, October 2000. 1070 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1071 Tunnel Broker", RFC 3053, January 2001. 1073 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1074 via IPv4 Clouds", RFC 3056, February 2001. 1076 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1077 of Explicit Congestion Notification (ECN) to IP", 1078 RFC 3168, September 2001. 1080 [RFC3484] Draves, R., "Default Address Selection for Internet 1081 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1083 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1084 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1085 September 2005. 1087 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1088 Network Address Translations (NATs)", RFC 4380, 1089 February 2006. 1091 [RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 1092 Enterprise Networks", RFC 4554, June 2006. 1094 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 1095 Layer (SEAL)", RFC 5320, February 2010. 1097 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 1098 RFC 5558, February 2010. 1100 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1101 Global Enterprise Recursion (RANGER)", RFC 5720, 1102 February 2010. 1104 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1105 Still Needs Work", RFC 5887, May 2010. 1107 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1108 Infrastructures (6rd) -- Protocol Specification", 1109 RFC 5969, August 2010. 1111 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 1112 Addressing in Networks with Global Enterprise Recursion 1113 (RANGER) Scenarios", RFC 6139, February 2011. 1115 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1116 Concerns with IP Tunneling", RFC 6169, April 2011. 1118 [RFC6179] Templin, F., "The Internet Routing Overlay Network 1119 (IRON)", RFC 6179, March 2011. 1121 Author's Address 1123 Fred L. Templin 1124 Boeing Research & Technology 1125 P.O. Box 3707 MC 7L-49 1126 Seattle, WA 98124 1127 USA 1129 Email: fltemplin@acm.org