idnits 2.17.1 draft-templin-v6ops-isops-13.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 (July 27, 2011) is 4654 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1918' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 794, 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) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-01 == Outdated reference: A later version (-04) exists of draft-templin-isupdate-01 -- 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: 3 errors (**), 0 flaws (~~), 5 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: BCP July 27, 2011 5 Expires: January 28, 2012 7 Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 8 draft-templin-v6ops-isops-13.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. This document 20 therefore provides operational guidance for deployment of IPv6 within 21 predominantly IPv4 sites using the Intra-Site Automatic Tunnel 22 Addressing Protocol (ISATAP). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 28, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Enabling IPv6 Services using ISATAP . . . . . . . . . . . . . 3 60 3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 5 62 3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 6 63 3.3. Reference Operational Scenario - Shared Prefix Model . . . 6 64 3.4. Reference Operational Scenario - Individual Prefix 65 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.5. SLAAC Site Administration Guidance . . . . . . . . . . . . 12 67 3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 14 68 3.7. Interface Identifier Compatibility Considerations . . . . 14 69 4. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 15 70 5. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 15 71 6. Site Renumbering Considerations . . . . . . . . . . . . . . . 16 72 7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 17 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 End user sites in the Internet today currently use IPv4 routing and 85 addressing internally for core operating functions such as web 86 browsing, filesharing, network printing, e-mail, teleconferencing and 87 numerous other site-internal networking services. Such sites 88 typically have an abundance of public or private IPv4 addresses for 89 internal networking, and are separated from the public Internet by 90 firewalls, packet filtering gateways, proxies, address translators 91 and other site border demarcation devices. To date, such sites have 92 had little incentive to enable IPv6 services internally [RFC1687]. 94 End-user sites that currently use IPv4 services internally come in 95 endless sizes and varieties. For example, a home network behind a 96 Network Address Translator (NAT) may consist of a single link 97 supporting a few laptops, printers etc. As a larger example, a small 98 business may consist of one or a few offices with several networks 99 connecting considerably larger numbers of computers, routers, 100 handheld devices, printers, faxes, etc. Moving further up the scale, 101 large banks, restaurants, major retailers, large corporations, etc. 102 may consist of hundreds or thousands of branches worldwide that are 103 tied together in a complex global enterprise network. Additional 104 examples include personal-area networks, mobile vehicular networks, 105 disaster relief networks, tactical military networks, and various 106 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 107 discussed in RANGERS[RFC6139]. 109 With the proliferation of IPv6 devices in the public Internet, 110 however, existing IPv4 sites will increasingly require a means for 111 enabling IPv6 services so that hosts within the site can communicate 112 with IPv6-only correspondents. Such services must be deployable with 113 minimal configuration, and in a fashion that will not cause 114 disruptions to existing IPv4 services. The Intra-Site Automatic 115 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 116 use service that sites can deploy in the near term to meet these 117 requirements. This document therefore provides operational guidance 118 for using ISATAP to enable IPv6 services within predominantly IPv4 119 sites while causing no disruptions to existing IPv4 services. The 120 terminology of ISATAP (see: [RFC5214], Section 3) applies also to 121 this document. 123 2. Enabling IPv6 Services using ISATAP 125 Existing sites within the Internet will soon need to enable IPv6 126 services. Larger sites typically obtain provider independent IPv6 127 prefixes from an Internet registry and advertise the prefixes into 128 the IPv6 routing system on their own behalf, i.e., they act as an 129 Internet Service Provider (ISP) unto themselves. Smaller sites that 130 wish to enable IPv6 can arrange to obtain public IPv6 prefixes from 131 an ISP, where the prefixes may be either purely native or the near- 132 native prefixes offered by 6rd [RFC5969]. Alternatively, the site 133 can obtain prefixes independently of an ISP e.g., via a tunnel broker 134 [RFC3053], by using one of its public IPv4 addresses to form a 6to4 135 prefix [RFC3056][RFC3068], etc. (Note however that experience shows 136 that the 6to4 method has some problems in current deployments that 137 can lead to connectivity failures [I-D.ietf-v6ops-6to4-advisory].) 138 In any case, after obtaining IPv6 prefixes the site can automatically 139 enable IPv6 services internally by configuring ISATAP. 141 The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) 142 tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in- 143 IPv4 encapsulation [RFC4213]. The encapsulation format can further 144 use Differentiated Service (DS) [RFC2983] and Explicit Congestion 145 Notification (ECN) [RFC3168] mapping between the inner and outer IP 146 headers to ensure expected per-hop behavior within well-managed 147 sites. 149 The ISATAP service is based on two node types known as advertising 150 ISATAP routers and ISATAP hosts. (A third node type known as non- 151 advertising ISATAP routers is defined in [I-D.templin-isupdate] but 152 out of scope for this document.) Each node may further have multiple 153 ISATAP interfaces (i.e., one interface for each site), and may act as 154 an advertising ISATAP router on some of those interfaces and a simple 155 ISATAP host on others. Hence, the node type is considered on a per- 156 interface basis. 158 Advertising ISATAP routers configure their ISATAP interfaces as 159 advertising router interfaces (see: [RFC4861], Section 6.2.2). 160 ISATAP hosts configure their ISATAP interfaces as simple host 161 interfaces and also coordinate their autoconfiguration operations 162 with advertising ISATAP routers. In this sense, advertising ISATAP 163 routers are "servers" while ISATAP hosts are "clients" in the service 164 model. 166 Advertising ISATAP routers arrange to add their IPv4 address to the 167 site's Potential Router List (PRL) so that ISATAP clients can 168 discover them, as discussed in Sections 8.3.2 and 9 of [RFC5214]. 169 Alternatively, site administrators could include IPv4 anycast 170 addresses in the PRL and assign each such address to multiple 171 advertising ISATAP routers. In that case, IPv4 routing within the 172 site would direct the ISATAP client to the nearest advertising ISATAP 173 router. 175 After the PRL is published, ISATAP clients within the site can 176 automatically perform unicast IPv6 Neighbor Discovery Router 177 Solicitation (RS) / Router Advertisement (RA) exchanges with 178 advertising ISATAP routers using IPv6-in-IPv4 encapsulation 179 [RFC4861][RFC5214]. In the exchange, the IPv4 source address of the 180 RS and the destination address of the RA are an IPv4 address of the 181 client, while the IPv4 destination address of the RS and the source 182 address of the RA are an IPv4 address of the server found in the PRL. 183 Similarly, the IPv6 source address of the RS and the destination 184 address of the RA are a link-local ISATAP address that embeds the 185 client's IPv4 address, while the IPv6 destination address of the RS 186 and the source address of the RA are a link-local ISATAP address that 187 embeds the server's IPv4 address. 189 Following router discovery, ISATAP clients can configure and assign 190 IPv6 addresses and/or prefixes using Stateless Address 191 AutoConfiguration (SLAAC) [RFC4862][RFC5214]. While out of scope for 192 this document, use of the Dynamic Host Configuration Protocol for 193 IPv6 (DHCPv6) [RFC3315] is also possible when necessary updates to 194 the ISATAP base specification are implemented [I-D.templin-isupdate]. 196 3. SLAAC Services 198 Predominantly IPv4 sites can enable SLAAC services for ISATAP clients 199 that need to communicate with IPv6 correspondents. SLAAC services 200 are enabled using either the "shared" or "individual" prefix model. 201 In the shared prefix model, all advertising ISATAP routers advertise 202 a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the 203 site. In the individual prefix model, advertising ISATAP router 204 advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0: 205 2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within the site. 206 Note that combinations of the shared and individual prefix models are 207 also possible, in which some of the site's ISATAP routers advertise 208 shared prefixes and others advertise individual prefixes. 210 The following sections discuss operational considerations for 211 enabling ISATAP SLAAC services within predominantly IPv4 sites. 213 3.1. Advertising ISATAP Router Behavior 215 Advertising ISATAP routers that support SLAAC services send RA 216 messages in response to RS messages received on an advertising ISATAP 217 interface. SLAAC services are enabled when advertising ISATAP 218 routers advertise non-link-local IPv6 prefixes in Prefix Information 219 Options (PIOs) with the A flag set to 1[RFC4861]. When there are 220 multiple advertising ISATAP routers, the routers can advertise a 221 shared IPv6 prefix or individual IPv6 prefixes. 223 3.2. ISATAP Host Behavior 225 ISATAP hosts resolve the PRL and send RS messages to obtain RA 226 messages from an advertising ISATAP router. When the host receives 227 RA messages, it uses SLAAC to configure IPv6 addresses from any 228 advertised prefixes with the A flag set to 1 as specified in 229 [RFC4862][RFC5214] then assigns the addresses to the ISATAP 230 interface. The host also assigns any of the advertised prefixes with 231 the L flag set to 1 to the ISATAP interface. (Note that the IPv6 232 link-local prefix fe80::/64 is always considered on-link on an ISATAP 233 interface.) 235 3.3. Reference Operational Scenario - Shared Prefix Model 237 Figure 1 depicts a reference ISATAP network topology for allowing 238 hosts within a predominantly IPv4 site to configure ISATAP services 239 using SLAAC with the shared prefix model. The scenario shows two 240 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 241 and an ordinary IPv6 host ('E') outside of the site in a typical 242 deployment configuration. In this model, routers 'A' and 'B' both 243 advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 244 routing system, and also advertise the prefix to ISATAP clients 245 within the site for SLAAC purposes. 247 .-(::::::::) 2001:db8:1::1 248 .-(::: IPv6 :::)-. +-------------+ 249 (:::: Internet ::::) | IPv6 Host E | 250 `-(::::::::::::)-' +-------------+ 251 `-(::::::)-' 252 ,~~~~~~~~~~~~~~~~~, 253 ,----|companion gateway|--. 254 / '~~~~~~~~~~~~~~~~~' : 255 / |. 256 ,-' `. 257 ; +------------+ +------------+ ) 258 : | Router A | | Router B | / 259 : | (isatap) | | (isatap) | : 260 : | 192.0.2.1 | | 192.0.2.1 | ; 261 + +------------+ +------------+ \ 262 fe80::*:192.0.2.1 fe80::*:192.0.2.1 263 | 2001:db8::/64 2001:db8::/64 | 264 | ; 265 : IPv4 Site -+-' 266 `-. (PRL: 192.0.2.1) .) 267 \ _) 268 `-----+--------)----+'----' 269 fe80::*:192.0.2.18 fe80::*:192.0.2.34 270 2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34 271 +--------------+ +--------------+ 272 | (isatap) | | (isatap) | 273 | Host C | | Host D | 274 +--------------+ +--------------+ 276 (* == "5efe") 278 Figure 1: Reference ISATAP Network Topology using Shared Prefix Model 280 With reference to Figure 1, advertising ISATAP routers 'A' and 'B' 281 within the IPv4 site connect to the IPv6 Internet either directly or 282 via a companion gateway. The routers advertise the shared prefix 283 2001:db8::/64 into the IPv6 Internet routing system either as a 284 singleton /64 or as part of a shorter aggregated IPv6 prefix if the 285 routing system will not accept prefixes as long as a /64. For the 286 purpose of this example, we also assume that the IPv4 site is 287 configured within multiple IPv4 subnets - each with an IPv4 prefix 288 length of /28. 290 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 291 anycast address 192.0.2.1 on a site-interior IPv4 interface, then 292 configure an advertising ISATAP router interface for the site with 293 link-local ISATAP address fe80::5efe:192.0.2.1. The site 294 administrator then places the single IPv4 address 192.0.2.1 in the 295 site's PRL. 'A' and 'B' then both advertise the anycast address/ 296 prefix into the site's IPv4 routing system so that ISATAP clients can 297 locate the router that is topologically closest. (Note: advertising 298 ISATAP routers can also use individual IPv4 unicast addresses instead 299 of, or in addition to, a shared IPv4 anycast address. In that case, 300 the PRL will contain multiple IPv4 addresses of advertising routers - 301 some of which may be anycast and others unicast.) 303 ISATAP host 'C' connects to the site via an IPv4 interface with 304 address 192.0.2.18/28, and also configures an ISATAP host interface 305 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 306 interface. 'C' next resolves the PRL, and sends an RS message to the 307 IPv4 address 192.0.2.1, where IPv4 routing will direct it to the 308 closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives 309 an RA from 'A' then configures a default IPv6 route with next-hop 310 address fe80::5efe:192.0.2.1 via the ISATAP interface and processes 311 the IPv6 prefix 2001:db8::/64 advertised in the PIO. If the A flag 312 is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 313 address 2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP 314 interface identifier) and assigns it to the ISATAP interface. If the 315 L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the 316 ISATAP interface, and the IPv6 address becomes a true ISATAP address. 318 In the same fashion, ISATAP host 'D' configures its IPv4 interface 319 with address 192.0.2.34/28 and configures its ISATAP interface with 320 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 321 an RS/RA exchange that is serviced by 'B', then uses SLAAC to 322 autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default 323 IPv6 route with next-hop address fe80::5efe:192.0.2.1. Finally, IPv6 324 host 'E' connects to an IPv6 network outside of the site. 'E' 325 configures its IPv6 interface in a manner specific to its attached 326 IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1. 328 Following this autoconfiguration, when host 'C' inside the site has 329 an IPv6 packet to send to host 'E' outside the site, it prepares the 330 packet with source address 2001:db8::5efe:192.0.2.18 and destination 331 address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to 332 forward the packet to the IPv4 address 192.0.2.1 which will be 333 directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the 334 packet and forwards it into the public IPv6 Internet where it will be 335 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 336 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 337 send IPv6 packets to IPv6 Internet hosts such as 'E'. 339 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 340 inside the site, the IPv6 routing system may direct the packet to 341 either of 'A' or 'B'. If the site is not partitioned internally, the 342 router that receives the packet can use ISATAP to statelessly forward 343 the packet directly to 'C'. If the site may be partitioned 344 internally, however, the packet must first be forwarded to 'C's 345 serving router based on IPv6 routing information. This implies that, 346 in a partitioned site, the advertising ISATAP routers must connect 347 within a full or partial mesh of IPv6 links, and must either run a 348 dynamic IPv6 routing protocol or configure static routes so that 349 incoming IPv6 packets can be forwarded to the correct serving router. 351 In this example, 'A' can configure the IPv6 route 2001:db8::5efe: 352 192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in 353 the mesh network as the next hop, and 'B' can configure the IPv6 354 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next 355 hop toward 'A' as the next hop. (Notice that the /124 prefixes 356 properly cover the /28 prefix of the IPv4 address that is embedded 357 within the IPv6 address.) In that case, when 'A' receives a packet 358 from the IPv6 Internet with destination address 2001:db8::5efe: 359 192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh 360 link. 'B' in turn uses ISATAP to forward the packet into the site, 361 where IPv4 routing will direct it to 'D'. In the same fashion, when 362 'B' receives a packet from the IPv6 Internet with destination address 363 2001:db8::5efe:192.0.2.18, it first forwards the packet toward 'A' 364 over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet 365 into the site, where IPv4 routing will direct it to 'C'. 367 Finally, when host 'C' inside the site connects to host 'D' inside 368 the site, it has the option of using the native IPv4 service or the 369 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 370 assurance that IPv4 services between the two hosts are available, the 371 hosts may be better served to continue to use legacy IPv4 services in 372 order to avoid encapsulation overhead and to avoid any IPv4 373 protocol-41 filtering middleboxes that may be in the path. If 'C' 374 and 'D' may be in different IPv4 network partitions, however, IPv6- 375 in-IPv4 encapsulation should be used with one or both of routers 'A' 376 and 'B' serving as intermediate gateways. 378 3.4. Reference Operational Scenario - Individual Prefix Model 380 Figure 2 depicts a reference ISATAP network topology for allowing 381 hosts within a predominantly IPv4 site to configure ISATAP services 382 using SLAAC with the individual prefix model. The scenario shows two 383 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 384 and an ordinary IPv6 host ('E') outside of the site in a typical 385 deployment configuration. In the figure, ISATAP routers 'A' and 'B' 386 both advertise different prefixes taken from the aggregated prefix 387 2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B' 388 advertising 2001:db8:0:2::/64. 390 .-(::::::::) 2001:db8:1::1 391 .-(::: IPv6 :::)-. +-------------+ 392 (:::: Internet ::::) | IPv6 Host E | 393 `-(::::::::::::)-' +-------------+ 394 `-(::::::)-' 395 ,~~~~~~~~~~~~~~~~~, 396 ,----|companion gateway|--. 397 / '~~~~~~~~~~~~~~~~~' : 398 / |. 399 ,-' `. 400 ; +------------+ +------------+ ) 401 : | Router A | | Router B | / 402 : | (isatap) | | (isatap) | : 403 : | 192.0.2.1 | | 192.0.2.1 | ; 404 + +------------+ +------------+ \ 405 fe80::*:192.0.2.1 fe80::*:192.0.2.1 406 2001:db8:0:1::/64 2001:db8:0:2::/64 407 | ; 408 : IPv4 Site -+-' 409 `-. (PRL: 192.0.2.1) .) 410 \ _) 411 `-----+--------)----+'----' 412 fe80::*:192.0.2.18 fe80::*:192.0.2.34 413 2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34 414 +--------------+ +--------------+ 415 | (isatap) | | (isatap) | 416 | Host C | | Host D | 417 +--------------+ +--------------+ 419 (* == "5efe") 421 Figure 2: Reference ISATAP Network Topology using Individual Prefix 422 Model 424 With reference to Figure 2, advertising ISATAP routers 'A' and 'B' 425 within the IPv4 site connect to the IPv6 Internet either directly or 426 via a companion gateway. Router 'A' advertises the individual prefix 427 2001:db8:0:1::/64 into the IPv6 Internet routing system, and router 428 'B' advertises the individual prefix 2001:db8:0:2::/64. The routers 429 could instead both advertise a shorter shared prefix such as 2001: 430 db8::/48 into the IPv6 routing system, but in that case they would 431 need to configure a mesh of IPv6 links between themselves in the same 432 fashion as described for the shared prefix model in Section 3.4. For 433 the purpose of this example, we also assume that the IPv4 site is 434 configured within multiple IPv4 subnets - each with an IPv4 prefix 435 length of /28. 437 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 438 anycast address 192.0.2.1 on a site-interior IPv4 interface, then 439 configure an advertising ISATAP router interface for the site with 440 link-local ISATAP address fe80::5efe:192.0.2.1. The site 441 administrator then places the single IPv4 address 192.0.2.1 in the 442 site's PRL. 'A' and 'B' then both advertise the anycast address/ 443 prefix into the site's IPv4 routing system so that ISATAP clients can 444 locate the router that is topologically closest. (Note: advertising 445 ISATAP routers can also use individual IPv4 unicast addresses instead 446 of, or in addition to, a shared IPv4 anycast address. In that case, 447 the PRL will contain multiple IPv4 addresses of advertising routers - 448 some of which may be anycast and others unicast.) 450 ISATAP host 'C' connects to the site via an IPv4 interface with 451 address 192.0.2.18/28, and also configures an ISATAP host interface 452 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 453 interface. 'C' next resolves the PRL, and sends an RS message to the 454 IPv4 address 192.0.2.1, where IPv4 routing will direct it to the 455 closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives 456 an RA from 'A' then configures a default IPv6 route with next-hop 457 address fe80::5efe:192.0.2.1 via the ISATAP interface and processes 458 the IPv6 prefix 2001:db8:0:1:/64 advertised in the PIO. If the A 459 flag is set in the PIO, 'C' uses SLAAC to automatically configure the 460 IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (i.e., an address with an 461 ISATAP interface identifier) and assigns it to the ISATAP interface. 462 If the L flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 463 to the ISATAP interface, and the IPv6 address becomes a true ISATAP 464 address. 466 In the same fashion, ISATAP host 'D' configures its IPv4 interface 467 with address 192.0.2.34/28 and configures its ISATAP interface with 468 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 469 an RS/RA exchange that is serviced by 'B', then uses SLAAC to 470 autoconfigure the address 2001:db8:0:2::5efe:192.0.2.34 and a default 471 IPv6 route with next-hop address fe80::5efe:192.0.2.1. Finally, IPv6 472 host 'E' connects to an IPv6 network outside of the site. 'E' 473 configures its IPv6 interface in a manner specific to its attached 474 IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1. 476 Following this autoconfiguration, when host 'C' inside the site has 477 an IPv6 packet to send to host 'E' outside the site, it prepares the 478 packet with source address 2001:db8::5efe:192.0.2.18 and destination 479 address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to 480 forward the packet to the IPv4 address 192.0.2.1 which will be 481 directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the 482 packet and forwards it into the public IPv6 Internet where it will be 483 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 484 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 485 send IPv6 packets to IPv6 Internet hosts such as 'E'. 487 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 488 inside the site, the IPv6 routing system will direct the packet to 489 'A' since 'A' advertises the individual prefix that matches 'C's 490 destination address. 'A' can then use ISATAP to statelessly forward 491 the packet directly to 'C'. If 'A' and 'B' both advertise the shared 492 shorter prefix 2001:db8::/48 into the IPv6 routing system, however 493 packets coming from 'E' may be directed to either 'A' or 'B'. In 494 that case, the advertising ISATAP routers must connect within a full 495 or partial mesh of IPv6 links the same as for the shared prefix 496 model, and must either run a dynamic IPv6 routing protocol or 497 configure static routes so that incoming IPv6 packets can be 498 forwarded to the correct serving router. 500 In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 501 with the IPv6 address of the next hop toward 'B' in the mesh network 502 as the next hop, and 'B' can configure the IPv6 route 2001:db8: 503 0.1::/64 with the IPv6 address of the next hop toward 'A' as the next 504 hop. Then, when 'A' receives a packet from the IPv6 Internet with 505 destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards 506 the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses 507 ISATAP to forward the packet into the site, where IPv4 routing will 508 direct it to 'D'. In the same fashion, when 'B' receives a packet 509 from the IPv6 Internet with destination address 2001:db8:0:1::5efe: 510 192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh 511 link. 'A' then uses ISATAP to forward the packet into the site, 512 where IPv4 routing will direct it to 'C'. 514 Finally, when host 'C' inside the site connects to host 'D' inside 515 the site, it has the option of using the native IPv4 service or the 516 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 517 assurance that IPv4 services between the two hosts are available, the 518 hosts may be better served to continue to use legacy IPv4 services in 519 order to avoid encapsulation overhead and to avoid any IPv4 520 protocol-41 filtering middleboxes that may be in the path. If 'C' 521 and 'D' may be in different IPv4 network partitions, however, IPv6- 522 in-IPv4 encapsulation should be used with one or both of routers 'A' 523 and 'B' serving as intermediate gateways. 525 3.5. SLAAC Site Administration Guidance 527 In common practice, firewalls, gateways and packet filtering devices 528 of various forms are often deployed in order to divide the site into 529 separate partitions. In both the shared and individual prefix models 530 described above, the entire site can be represented by the aggregate 531 IPv6 prefix assigned to the site, while each site partition can be 532 represented by "sliver" IPv6 prefixes taken from the aggregate. In 533 order to provide a simple service that does not interact poorly with 534 the site topology, site administrators should therefore institute an 535 address plan to align IPv6 sliver prefixes with IPv4 site partition 536 boundaries. 538 For example, in the shared prefix model in Section 3.3, the aggregate 539 prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe: 540 192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe: 541 192.0.2.32/124, etc. In the individual prefix model in Section 3.4, 542 the aggregate prefix is 2001:db8::/48 and the sliver prefixes are 543 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc. 545 When individual prefixes are used, site administrators can configure 546 advertising ISATAP routers to advertise different individual prefixes 547 to different sets of clients, e.g., based on the client's IPv4 subnet 548 prefix. (For example, administrators can configure each advertising 549 ISATAP router to provide services only to certain sets of ISATAP 550 clients through inbound IPv6 Access Control List (ACL) entries that 551 match the IPv4 subnet prefix embedded in the ISATAP interface 552 identifier of the IPv6 source address). When a shared prefix is 553 used, site administrators instead configure the ISATAP routers to 554 advertise the shared prefix to all clients. 556 Advertising ISATAP routers can advertise prefixes with the (A, L) 557 flags set to (1,0) so that ISATAP clients will use SLAAC to 558 autoconfigure IPv6 addresses with ISATAP interface identifiers from 559 the prefixes and assign them to the receiving ISATAP interface, but 560 they will not assign the prefix itself to the ISATAP interface. In 561 that case, the advertising router must assign the sliver prefix for 562 the site partition to the advertising ISATAP interface. In this way, 563 the advertising router considers the addresses covered by the sliver 564 prefix as true ISATAP addresses, but the ISATAP clients themselves do 565 not. This configuration enables a hub-and-spokes architecture which 566 in some cases may be augmented by route optimization based on the 567 receipt of ICMPv6 Redirects. 569 Site administrators can implement address selection policy rules 570 [RFC3484] through explicit configurations in each ISATAP client. 571 Site administrators implement this policy by configuring address 572 selection policy rules [RFC3484] in each ISATAP client in order to 573 give preference to IPv4 destination addresses over destination 574 addresses derived from one of the client's IPv6 sliver prefixes. 576 For example, site administrators can configure each ISATAP client 577 associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124 578 to add the prefix to its address selection policy table with a lower 579 precedence than the prefix ::ffff:0:0/96. In this way, IPv4 580 addresses are preferred over IPv6 addresses from within the same 581 sliver. The prefix could be added to each ISATAP client either 582 manually, or through an automated service such as a DHCP option 584 [I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4 585 communications to reach correspondents within the same IPv4 site 586 partition, and will use IPv6 communications to reach correspondents 587 in other partitions and/or outside of the site. 589 It should be noted that sliver prefixes longer than /64 cannot be 590 advertised for SLAAC purposes. Also, sliver prefixes longer than /64 591 do not allow for interface identifier rewriting by address 592 translators. These factors may favor the individual prefix model in 593 some deployment scenarios, while the flexibility afforded by the 594 shared prefix model may be more desirable in others. Additionally, 595 if the network is small then the shared prefix model works well. If 596 the network is large, however, a better alternative may be to deploy 597 separate ISATAP routers in each region and have each advertise their 598 own individual prefix. 600 Finally, site administrators should configure ISATAP routers to not 601 send ICMPv6 Redirect messages to inform a source client of a better 602 next hop toward the destination unless there is strong assurance that 603 the client and the next hop are within the same IPv4 site partition. 605 3.6. Loop Avoidance 607 In sites that provide IPv6 services through ISATAP with SLAAC as 608 described in this section, site administrators must take operational 609 precautions to avoid routing loops. For example, each advertising 610 ISATAP router should drop any incoming IPv6 packets that would be 611 forwarded back to itself via another of the site's advertising 612 routers. Additionally, each advertising ISATAP router should drop 613 any encapsulated packets received from another advertising router 614 that would be forwarded back to that same advertising router. This 615 corresponds to the mitigation documented in Section 3.2.3 of 616 [I-D.ietf-v6ops-tunnel-loops], but other mitigations specified in 617 that document can also be employed. 619 Note that IPv6 packets with link-local ISATAP addresses are exempt 620 from these checks, since they cannot be forwarded by an IPv6 router 621 and may be necessary for router-to-router coordinations. 623 3.7. Interface Identifier Compatibility Considerations 625 [RFC5214] Section 6.1 specifies the setting of the "u" bit in the 626 Modified EUI-64 interface identifier format used by ISATAP. 627 Implementations that comply with the specification set the "u" bit to 628 1 when the IPv4 address is known to be globally unique, however some 629 legacy implementations unconditionally set the "u" bit to 0. 631 Implementations interpret the ISATAP interface identifier only within 632 the link to which the corresponding ISATAP prefix is assigned, hence 633 the value of the "u" bit is interpreted only within the context of an 634 on-link prefix and not within a global context. Implementers are 635 responsible for ensuring that their products are interoperable, 636 therefore implementations must make provisions for ensuring "u" bit 637 compatibility for intra-link communications. 639 Site administrators should accordingly configure access control list 640 entries and other literal representations of ISATAP interface 641 identifiers such that both values of the "u" bit are accepted. For 642 example, if the site administrator configures an access control list 643 entry that matches the prefix "fe80::0000:5efe:192.0.2.0/124" they 644 should also configure a companion list entry that matches the prefix 645 "fe80::0200:5efe:192.0.2.0/124. 647 4. Manual Configuration 649 When no autoconfiguration services are available (e.g., if there are 650 no advertising ISATAP routers present), site administrators can use 651 manual configuration to assign IPv6 addresses with ISATAP interface 652 identifiers to the ISATAP interfaces of clients. Otherwise, site 653 administrators should avoid manual configurations that would in any 654 way invalidate the assumptions of the autoconfiguration service. For 655 example, manually configured addresses may not be automatically 656 renumbered during a site-wide renumbering event, which could 657 subsequently result in communication failures. 659 5. Scaling Considerations 661 Section 3 depicts ISATAP network topologies with only two advertising 662 ISATAP routers within the site. In order to support larger numbers 663 of ISATAP clients (and/or multiple site partitions), the site can 664 deploy more advertising ISATAP routers to support load balancing and 665 generally shortest-path routing. 667 Such an arrangement requires that the advertising ISATAP routers 668 participate in an IPv6 routing protocol instance so that IPv6 669 addresses/prefixes can be mapped to the correct ISATAP router. The 670 routing protocol instance can be configured as either a full mesh 671 topology involving all advertising ISATAP routers, or as a partial 672 mesh topology with each advertising ISATAP router associating with 673 one or more companion gateways. Each such companion gateway would in 674 turn participate in a full mesh between all companion gateways. 676 6. Site Renumbering Considerations 678 Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients 679 within the site. If the site subsequently reconnects to a different 680 ISP, however, the site must renumber to use addresses derived from 681 the new IPv6 prefixes [RFC1900][RFC4192][RFC5887]. 683 For IPv6 services provided by SLAAC, site renumbering in the event of 684 a change in an ISP-served IPv6 prefix entails a simple renumbering of 685 IPv6 addresses and/or prefixes that are assigned to the ISATAP 686 interfaces of clients within the site. In some cases, filtering 687 rules (e.g., within site border firewall filtering tables) may also 688 require renumbering, but this operation can be automated and limited 689 to only one or a few administrative "touch points". 691 In order to renumber the ISATAP interfaces of clients within the site 692 using SLAAC, advertising ISATAP routers need only schedule the 693 services offered by the old ISP for deprecation and begin to 694 advertise the IPv6 prefixes provided by the new ISP. ISATAP client 695 interface address lifetimes will eventually expire, and the host will 696 renumber its interfaces with addresses derived from the new prefixes. 697 ISATAP clients should also eventually remove any deprecated SLAAC 698 prefixes from their address selection policy tables, but this action 699 is not time-critical. 701 Finally, site renumbering in the event of a change in an ISP-served 702 IPv6 prefix further entails locating and rewriting all IPv6 addresses 703 in naming services, databases, configuration files, packet filtering 704 rules, documentation, etc. If the site has published the IPv6 705 addresses of any site-internal nodes within the public Internet DNS 706 system, then the corresponding resource records will also need to be 707 updated during the renumbering operation. This can be accomplished 708 via secure dynamic updates to the DNS. 710 7. Path MTU Considerations 712 IPv6-in-IPv4 encapsulation overhead effectively reduces the size of 713 IPv6 packets that can traverse the tunnel in relation to the actual 714 Maximum Transmission Unit (MTU) of the underlying IPv4 network path 715 between the encapsulator and decapsulator. Two methods for 716 accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels 717 (i.e., the static and dynamic methods) are documented in Section 3.2 718 of [RFC4213]. 720 The static method places a "safe" upper bound on the size of IPv6 721 packets permitted to enter the tunnel, however the method can be 722 overly conservative when larger IPv4 path MTUs are available. The 723 dynamic method can accommodate much larger IPv6 packet sizes in some 724 cases, but can fail silently if the underlying IPv4 network path does 725 not return the necessary error messages. 727 This document notes that sites that include well-managed IPv4 links, 728 routers and other network middleboxes are candidates for use of the 729 dynamic MTU determination method, which may provide for a better 730 operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. 731 The dynamic MTU determination method can potentially also present a 732 larger MTU to IPv6 correspondents outside of the site, since IPv6 733 path MTU discovery is considered robust even over the wide area in 734 the public IPv6 Internet. 736 8. Alternative Approaches 738 [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in 739 enterprise networks. The ISATAP approach provides a more flexible 740 and broadly-applicable alternative, and with fewer administrative 741 touch points. 743 The tunnel broker service [RFC3053] uses point-to-point tunnels that 744 require end users to establish an explicit administrative 745 configuration of the tunnel far end, which may be outside of the 746 administrative boundaries of the site. 748 6to4 [RFC3056][RFC3068] and Teredo [RFC4380] provide "last resort" 749 unmanaged automatic tunneling services when no other means for IPv6 750 connectivity is available. These services are given lower priority 751 when the ISATAP managed service and/or native IPv6 services are 752 enabled. 754 6rd [RFC5969] enables a stateless prefix delegation capability based 755 on IPv4-embedded IPv6 prefixes, whereas ISATAP enables a stateful 756 prefix delegation capability based on native IPv6 prefixes. 758 IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] 759 were developed as the "next-generation" of ISATAP and extend to a 760 wide variety of use cases [RFC6139]. However, these technologies are 761 not yet widely implemented or deployed. 763 9. IANA Considerations 765 This document has no IANA considerations. 767 10. Security Considerations 769 In addition to the security considerations documented in [RFC5214], 770 sites that use ISATAP should take care to ensure that no routing 771 loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security 772 concerns with IP tunneling are documented in [RFC6169]. 774 11. Acknowledgments 776 The following are acknowledged for their insights that helped shape 777 this work: Dmitry Anipko, Fred Baker, Brian Carpenter, Remi Despres, 778 Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel 779 Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer, Hemant Singh, 780 Mark Smith, Ole Troan, Gunter Van de Velde, ... 782 12. References 784 12.1. Normative References 786 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 787 E. Lear, "Address Allocation for Private Internets", 788 BCP 5, RFC 1918, February 1996. 790 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 791 and M. Carney, "Dynamic Host Configuration Protocol for 792 IPv6 (DHCPv6)", RFC 3315, July 2003. 794 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 795 Host Configuration Protocol (DHCP) version 6", RFC 3633, 796 December 2003. 798 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 799 for IPv6 Hosts and Routers", RFC 4213, October 2005. 801 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 802 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 803 September 2007. 805 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 806 Address Autoconfiguration", RFC 4862, September 2007. 808 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 809 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 810 March 2008. 812 12.2. Informative References 814 [I-D.ietf-6man-addr-select-opt] 815 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 816 "Distributing Address Selection Policy using DHCPv6", 817 draft-ietf-6man-addr-select-opt-01 (work in progress), 818 June 2011. 820 [I-D.ietf-v6ops-6to4-advisory] 821 Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 822 draft-ietf-v6ops-6to4-advisory-02 (work in progress), 823 June 2011. 825 [I-D.ietf-v6ops-tunnel-loops] 826 Nakibly, G. and F. Templin, "Routing Loop Attack using 827 IPv6 Automatic Tunnels: Problem Statement and Proposed 828 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 829 progress), May 2011. 831 [I-D.templin-isupdate] 832 Templin, F., "ISATAP Updates", draft-templin-isupdate-01 833 (work in progress), July 2011. 835 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 836 RFC 1687, August 1994. 838 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 839 RFC 1900, February 1996. 841 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 842 over Non-Broadcast Multiple Access (NBMA) networks", 843 RFC 2491, January 1999. 845 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 846 Domains without Explicit Tunnels", RFC 2529, March 1999. 848 [RFC2983] Black, D., "Differentiated Services and Tunnels", 849 RFC 2983, October 2000. 851 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 852 Tunnel Broker", RFC 3053, January 2001. 854 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 855 via IPv4 Clouds", RFC 3056, February 2001. 857 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 858 RFC 3068, June 2001. 860 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 861 of Explicit Congestion Notification (ECN) to IP", 862 RFC 3168, September 2001. 864 [RFC3484] Draves, R., "Default Address Selection for Internet 865 Protocol version 6 (IPv6)", RFC 3484, February 2003. 867 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 868 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 869 September 2005. 871 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 872 Network Address Translations (NATs)", RFC 4380, 873 February 2006. 875 [RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 876 Enterprise Networks", RFC 4554, June 2006. 878 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 879 Layer (SEAL)", RFC 5320, February 2010. 881 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 882 RFC 5558, February 2010. 884 [RFC5720] Templin, F., "Routing and Addressing in Networks with 885 Global Enterprise Recursion (RANGER)", RFC 5720, 886 February 2010. 888 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 889 Still Needs Work", RFC 5887, May 2010. 891 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 892 Infrastructures (6rd) -- Protocol Specification", 893 RFC 5969, August 2010. 895 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 896 Addressing in Networks with Global Enterprise Recursion 897 (RANGER) Scenarios", RFC 6139, February 2011. 899 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 900 Concerns with IP Tunneling", RFC 6169, April 2011. 902 [RFC6179] Templin, F., "The Internet Routing Overlay Network 903 (IRON)", RFC 6179, March 2011. 905 Author's Address 907 Fred L. Templin 908 Boeing Research & Technology 909 P.O. Box 3707 MC 7L-49 910 Seattle, WA 98124 911 USA 913 Email: fltemplin@acm.org