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