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