idnits 2.17.1 draft-templin-v6ops-isops-14.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 (October 13, 2011) is 4550 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 788, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 796, 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 October 13, 2011 5 Expires: April 15, 2012 7 Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 8 draft-templin-v6ops-isops-14.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 April 15, 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 [RFC6343].) In any case, after 138 obtaining IPv6 prefixes the site can automatically enable IPv6 139 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 is a link-local ISATAP 184 address that embeds the client's IPv4 address, while the source 185 address of the RA is a link-local ISATAP address that embeds the 186 server's IPv4 address. (The destination addresses of the RS and RA 187 may be either the neighbor's link-local ISATAP address or a link- 188 scoped multicast address depending on the implementation.) 190 Following router discovery, ISATAP clients can configure and assign 191 IPv6 addresses and/or prefixes using Stateless Address 192 AutoConfiguration (SLAAC) [RFC4862][RFC5214]. While out of scope for 193 this document, use of the Dynamic Host Configuration Protocol for 194 IPv6 (DHCPv6) [RFC3315] is also possible when necessary updates to 195 the ISATAP base specification are implemented [I-D.templin-isupdate]. 197 3. SLAAC Services 199 Predominantly IPv4 sites can enable SLAAC services for ISATAP clients 200 that need to communicate with IPv6 correspondents. SLAAC services 201 are enabled using either the "shared" or "individual" prefix model. 202 In the shared prefix model, all advertising ISATAP routers advertise 203 a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the 204 site. In the individual prefix model, advertising ISATAP router 205 advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0: 206 2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within partition 207 of the site. Note that combinations of the shared and individual 208 prefix models are also possible, in which some of the site's ISATAP 209 routers advertise shared prefixes and others advertise individual 210 prefixes. 212 The following sections discuss operational considerations for 213 enabling ISATAP SLAAC services within predominantly IPv4 sites. 215 3.1. Advertising ISATAP Router Behavior 217 Advertising ISATAP routers that support SLAAC services send RA 218 messages in response to RS messages received on an advertising ISATAP 219 interface. SLAAC services are enabled when advertising ISATAP 220 routers advertise non-link-local IPv6 prefixes in Prefix Information 221 Options (PIOs) with the A flag set to 1[RFC4861]. When there are 222 multiple advertising ISATAP routers, the routers can advertise a 223 shared IPv6 prefix or individual IPv6 prefixes. 225 3.2. ISATAP Host Behavior 227 ISATAP hosts resolve the PRL and send RS messages to obtain RA 228 messages from an advertising ISATAP router. When the host receives 229 RA messages, it uses SLAAC to configure IPv6 addresses from any 230 advertised prefixes with the A flag set to 1 as specified in 231 [RFC4862][RFC5214] then assigns the addresses to the ISATAP 232 interface. The host also assigns any of the advertised prefixes with 233 the L flag set to 1 to the ISATAP interface. (Note that the IPv6 234 link-local prefix fe80::/64 is always considered on-link on an ISATAP 235 interface.) 237 3.3. Reference Operational Scenario - Shared Prefix Model 239 Figure 1 depicts an example ISATAP network topology for allowing 240 hosts within a predominantly IPv4 site to configure ISATAP services 241 using SLAAC with the shared prefix model. The example shows two 242 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 243 and an ordinary IPv6 host ('E') outside of the site in a typical 244 deployment configuration. In this model, routers 'A' and 'B' both 245 advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 246 routing system, and also advertise the prefix to ISATAP clients 247 within the site for SLAAC purposes. 249 .-(::::::::) 2001:db8:1::1 250 .-(::: IPv6 :::)-. +-------------+ 251 (:::: Internet ::::) | IPv6 Host E | 252 `-(::::::::::::)-' +-------------+ 253 `-(::::::)-' 254 ,~~~~~~~~~~~~~~~~~, 255 ,----|companion gateway|--. 256 / '~~~~~~~~~~~~~~~~~' : 257 / |. 258 ,-' `. 259 ; +------------+ +------------+ ) 260 : | Router A | | Router B | / 261 : | (isatap) | | (isatap) | : 262 : | 192.0.2.1 | | 192.0.2.1 | ; 263 + +------------+ +------------+ \ 264 fe80::*:192.0.2.1 fe80::*:192.0.2.1 265 | 2001:db8::/64 2001:db8::/64 | 266 | ; 267 : IPv4 Site -+-' 268 `-. (PRL: 192.0.2.1) .) 269 \ _) 270 `-----+--------)----+'----' 271 fe80::*:192.0.2.18 fe80::*:192.0.2.34 272 2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34 273 +--------------+ +--------------+ 274 | (isatap) | | (isatap) | 275 | Host C | | Host D | 276 +--------------+ +--------------+ 278 (* == "5efe") 280 Figure 1: Example ISATAP Network Topology using Shared Prefix Model 282 With reference to Figure 1, advertising ISATAP routers 'A' and 'B' 283 within the IPv4 site connect to the IPv6 Internet either directly or 284 via a companion gateway. The routers advertise the shared prefix 285 2001:db8::/64 into the IPv6 Internet routing system either as a 286 singleton /64 or as part of a shorter aggregated IPv6 prefix if the 287 routing system will not accept prefixes as long as a /64. For the 288 purpose of this example, we also assume that the IPv4 site is 289 configured within multiple IPv4 subnets - each with an IPv4 prefix 290 length of /28. 292 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 293 anycast address 192.0.2.1 on a site-interior IPv4 interface, then 294 configure an advertising ISATAP router interface for the site with 295 link-local ISATAP address fe80::5efe:192.0.2.1. The site 296 administrator then places the single IPv4 address 192.0.2.1 in the 297 site's PRL. 'A' and 'B' then both advertise the anycast address/ 298 prefix into the site's IPv4 routing system so that ISATAP clients can 299 locate the router that is topologically closest. (Note: advertising 300 ISATAP routers can also use individual IPv4 unicast addresses instead 301 of, or in addition to, a shared IPv4 anycast address. In that case, 302 the PRL will contain multiple IPv4 addresses of advertising routers - 303 some of which may be anycast and others unicast.) 305 ISATAP host 'C' connects to the site via an IPv4 interface with 306 address 192.0.2.18/28, and also configures an ISATAP host interface 307 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 308 interface. 'C' next resolves the PRL, and sends an RS message to the 309 IPv4 address 192.0.2.1, where IPv4 routing will direct it to the 310 closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives 311 an RA from 'A' then configures a default IPv6 route with next-hop 312 address fe80::5efe:192.0.2.1 via the ISATAP interface and processes 313 the IPv6 prefix 2001:db8::/64 advertised in the PIO. If the A flag 314 is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 315 address 2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP 316 interface identifier) and assigns it to the ISATAP interface. If the 317 L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the 318 ISATAP interface, and the IPv6 address becomes a true ISATAP address. 320 In the same fashion, ISATAP host 'D' configures its IPv4 interface 321 with address 192.0.2.34/28 and configures its ISATAP interface with 322 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 323 an RS/RA exchange that is serviced by 'B', then uses SLAAC to 324 autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default 325 IPv6 route with next-hop address fe80::5efe:192.0.2.1. Finally, IPv6 326 host 'E' connects to an IPv6 network outside of the site. 'E' 327 configures its IPv6 interface in a manner specific to its attached 328 IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1. 330 Following this autoconfiguration, when host 'C' inside the site has 331 an IPv6 packet to send to host 'E' outside the site, it prepares the 332 packet with source address 2001:db8::5efe:192.0.2.18 and destination 333 address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to 334 forward the packet to the IPv4 address 192.0.2.1 which will be 335 directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the 336 packet and forwards it into the public IPv6 Internet where it will be 337 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 338 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 339 send IPv6 packets to IPv6 Internet hosts such as 'E'. 341 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 342 inside the site, the IPv6 routing system may direct the packet to 343 either of 'A' or 'B'. If the site is not partitioned internally, the 344 router that receives the packet can use ISATAP to statelessly forward 345 the packet directly to 'C'. If the site may be partitioned 346 internally, however, the packet must first be forwarded to 'C's 347 serving router based on IPv6 routing information. This implies that, 348 in a partitioned site, the advertising ISATAP routers must connect 349 within a full or partial mesh of IPv6 links, and must either run a 350 dynamic IPv6 routing protocol or configure static routes so that 351 incoming IPv6 packets can be forwarded to the correct serving router. 353 In this example, 'A' can configure the IPv6 route 2001:db8::5efe: 354 192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in 355 the mesh network as the next hop, and 'B' can configure the IPv6 356 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next 357 hop toward 'A' as the next hop. (Notice that the /124 prefixes 358 properly cover the /28 prefix of the IPv4 address that is embedded 359 within the IPv6 address.) In that case, when 'A' receives a packet 360 from the IPv6 Internet with destination address 2001:db8::5efe: 361 192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh 362 link. 'B' in turn uses ISATAP to forward the packet into the site, 363 where IPv4 routing will direct it to 'D'. In the same fashion, when 364 'B' receives a packet from the IPv6 Internet with destination address 365 2001:db8::5efe:192.0.2.18, it first forwards the packet toward 'A' 366 over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet 367 into the site, where IPv4 routing will direct it to 'C'. 369 Finally, when host 'C' inside the site connects to host 'D' inside 370 the site, it has the option of using the native IPv4 service or the 371 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 372 assurance that IPv4 services between the two hosts are available, the 373 hosts may be better served to continue to use legacy IPv4 services in 374 order to avoid encapsulation overhead and to avoid any IPv4 375 protocol-41 filtering middleboxes that may be in the path. If 'C' 376 and 'D' may be in different IPv4 network partitions, however, IPv6- 377 in-IPv4 encapsulation should be used with one or both of routers 'A' 378 and 'B' serving as intermediate gateways. 380 3.4. Reference Operational Scenario - Individual Prefix Model 382 Figure 2 depicts an example ISATAP network topology for allowing 383 hosts within a predominantly IPv4 site to configure ISATAP services 384 using SLAAC with the individual prefix model. The example shows two 385 advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), 386 and an ordinary IPv6 host ('E') outside of the site in a typical 387 deployment configuration. In the figure, ISATAP routers 'A' and 'B' 388 both advertise different prefixes taken from the aggregated prefix 389 2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B' 390 advertising 2001:db8:0:2::/64. 392 .-(::::::::) 2001:db8:1::1 393 .-(::: IPv6 :::)-. +-------------+ 394 (:::: Internet ::::) | IPv6 Host E | 395 `-(::::::::::::)-' +-------------+ 396 `-(::::::)-' 397 ,~~~~~~~~~~~~~~~~~, 398 ,----|companion gateway|--. 399 / '~~~~~~~~~~~~~~~~~' : 400 / |. 401 ,-' `. 402 ; +------------+ +------------+ ) 403 : | Router A | | Router B | / 404 : | (isatap) | | (isatap) | : 405 : | 192.0.2.1 | | 192.0.2.1 | ; 406 + +------------+ +------------+ \ 407 fe80::*:192.0.2.1 fe80::*:192.0.2.1 408 2001:db8:0:1::/64 2001:db8:0:2::/64 409 | ; 410 : IPv4 Site -+-' 411 `-. (PRL: 192.0.2.1) .) 412 \ _) 413 `-----+--------)----+'----' 414 fe80::*:192.0.2.18 fe80::*:192.0.2.34 415 2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34 416 +--------------+ +--------------+ 417 | (isatap) | | (isatap) | 418 | Host C | | Host D | 419 +--------------+ +--------------+ 421 (* == "5efe") 423 Figure 2: Example ISATAP Network Topology using Individual Prefix 424 Model 426 With reference to Figure 2, advertising ISATAP routers 'A' and 'B' 427 within the IPv4 site connect to the IPv6 Internet either directly or 428 via a companion gateway. Router 'A' advertises the individual prefix 429 2001:db8:0:1::/64 into the IPv6 Internet routing system, and router 430 'B' advertises the individual prefix 2001:db8:0:2::/64. The routers 431 could instead both advertise a shorter shared prefix such as 2001: 432 db8::/48 into the IPv6 routing system, but in that case they would 433 need to configure a mesh of IPv6 links between themselves in the same 434 fashion as described for the shared prefix model in Section 3.4. For 435 the purpose of this example, we also assume that the IPv4 site is 436 configured within multiple IPv4 subnets - each with an IPv4 prefix 437 length of /28. 439 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 440 anycast address 192.0.2.1 on a site-interior IPv4 interface, then 441 configure an advertising ISATAP router interface for the site with 442 link-local ISATAP address fe80::5efe:192.0.2.1. The site 443 administrator then places the single IPv4 address 192.0.2.1 in the 444 site's PRL. 'A' and 'B' then both advertise the anycast address/ 445 prefix into the site's IPv4 routing system so that ISATAP clients can 446 locate the router that is topologically closest. (Note: advertising 447 ISATAP routers can also use individual IPv4 unicast addresses instead 448 of, or in addition to, a shared IPv4 anycast address. In that case, 449 the PRL will contain multiple IPv4 addresses of advertising routers - 450 some of which may be anycast and others unicast.) 452 ISATAP host 'C' connects to the site via an IPv4 interface with 453 address 192.0.2.18/28, and also configures an ISATAP host interface 454 with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 455 interface. 'C' next resolves the PRL, and sends an RS message to the 456 IPv4 address 192.0.2.1, where IPv4 routing will direct it to the 457 closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives 458 an RA from 'A' then configures a default IPv6 route with next-hop 459 address fe80::5efe:192.0.2.1 via the ISATAP interface and processes 460 the IPv6 prefix 2001:db8:0:1:/64 advertised in the PIO. If the A 461 flag is set in the PIO, 'C' uses SLAAC to automatically configure the 462 IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (i.e., an address with an 463 ISATAP interface identifier) and assigns it to the ISATAP interface. 464 If the L flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 465 to the ISATAP interface, and the IPv6 address becomes a true ISATAP 466 address. 468 In the same fashion, ISATAP host 'D' configures its IPv4 interface 469 with address 192.0.2.34/28 and configures its ISATAP interface with 470 link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs 471 an RS/RA exchange that is serviced by 'B', then uses SLAAC to 472 autoconfigure the address 2001:db8:0:2::5efe:192.0.2.34 and a default 473 IPv6 route with next-hop address fe80::5efe:192.0.2.1. Finally, IPv6 474 host 'E' connects to an IPv6 network outside of the site. 'E' 475 configures its IPv6 interface in a manner specific to its attached 476 IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1. 478 Following this autoconfiguration, when host 'C' inside the site has 479 an IPv6 packet to send to host 'E' outside the site, it prepares the 480 packet with source address 2001:db8::5efe:192.0.2.18 and destination 481 address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to 482 forward the packet to the IPv4 address 192.0.2.1 which will be 483 directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the 484 packet and forwards it into the public IPv6 Internet where it will be 485 conveyed to 'E' via normal IPv6 routing. In the same fashion, host 486 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to 487 send IPv6 packets to IPv6 Internet hosts such as 'E'. 489 When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' 490 inside the site, the IPv6 routing system will direct the packet to 491 'A' since 'A' advertises the individual prefix that matches 'C's 492 destination address. 'A' can then use ISATAP to statelessly forward 493 the packet directly to 'C'. If 'A' and 'B' both advertise the shared 494 shorter prefix 2001:db8::/48 into the IPv6 routing system, however 495 packets coming from 'E' may be directed to either 'A' or 'B'. In 496 that case, the advertising ISATAP routers must connect within a full 497 or partial mesh of IPv6 links the same as for the shared prefix 498 model, and must either run a dynamic IPv6 routing protocol or 499 configure static routes so that incoming IPv6 packets can be 500 forwarded to the correct serving router. 502 In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 503 with the IPv6 address of the next hop toward 'B' in the mesh network 504 as the next hop, and 'B' can configure the IPv6 route 2001:db8: 505 0.1::/64 with the IPv6 address of the next hop toward 'A' as the next 506 hop. Then, when 'A' receives a packet from the IPv6 Internet with 507 destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards 508 the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses 509 ISATAP to forward the packet into the site, where IPv4 routing will 510 direct it to 'D'. In the same fashion, when 'B' receives a packet 511 from the IPv6 Internet with destination address 2001:db8:0:1::5efe: 512 192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh 513 link. 'A' then uses ISATAP to forward the packet into the site, 514 where IPv4 routing will direct it to 'C'. 516 Finally, when host 'C' inside the site connects to host 'D' inside 517 the site, it has the option of using the native IPv4 service or the 518 ISATAP IPv6-in-IPv4 encapsulation service. When there is operational 519 assurance that IPv4 services between the two hosts are available, the 520 hosts may be better served to continue to use legacy IPv4 services in 521 order to avoid encapsulation overhead and to avoid any IPv4 522 protocol-41 filtering middleboxes that may be in the path. If 'C' 523 and 'D' may be in different IPv4 network partitions, however, IPv6- 524 in-IPv4 encapsulation should be used with one or both of routers 'A' 525 and 'B' serving as intermediate gateways. 527 3.5. SLAAC Site Administration Guidance 529 In common practice, firewalls, gateways and packet filtering devices 530 of various forms are often deployed in order to divide the site into 531 separate partitions. In both the shared and individual prefix models 532 described above, the entire site can be represented by the aggregate 533 IPv6 prefix assigned to the site, while each site partition can be 534 represented by "sliver" IPv6 prefixes taken from the aggregate. In 535 order to provide a simple service that does not interact poorly with 536 the site topology, site administrators should therefore institute an 537 address plan to align IPv6 sliver prefixes with IPv4 site partition 538 boundaries. 540 For example, in the shared prefix model in Section 3.3, the aggregate 541 prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe: 542 192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe: 543 192.0.2.32/124, etc. In the individual prefix model in Section 3.4, 544 the aggregate prefix is 2001:db8::/48 and the sliver prefixes are 545 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc. 547 When individual prefixes are used, site administrators can configure 548 advertising ISATAP routers to advertise different individual prefixes 549 to different sets of clients, e.g., based on the client's IPv4 subnet 550 prefix such that the IPv6 prefixes are congruent with the IPv4 551 addressing plan. (For example, administrators can configure each 552 advertising ISATAP router to provide services only to certain sets of 553 ISATAP clients through inbound IPv6 Access Control List (ACL) entries 554 that match the IPv4 subnet prefix embedded in the ISATAP interface 555 identifier of the IPv6 source address). When a shared prefix is 556 used, site administrators instead configure the ISATAP routers to 557 advertise the shared prefix to all clients. 559 Advertising ISATAP routers can advertise prefixes with the (A, L) 560 flags set to (1,0) so that ISATAP clients will use SLAAC to 561 autoconfigure IPv6 addresses with ISATAP interface identifiers from 562 the prefixes and assign them to the receiving ISATAP interface, but 563 they will not assign the prefix itself to the ISATAP interface. In 564 that case, the advertising router must assign the sliver prefix for 565 the site partition to the advertising ISATAP interface. In this way, 566 the advertising router considers the addresses covered by the sliver 567 prefix as true ISATAP addresses, but the ISATAP clients themselves do 568 not. This configuration enables a hub-and-spokes architecture which 569 in some cases may be augmented by route optimization based on the 570 receipt of ICMPv6 Redirects. 572 Site administrators can implement address selection policy rules 573 [RFC3484] through explicit configurations in each ISATAP client. 574 Site administrators implement this policy by configuring address 575 selection policy rules [RFC3484] in each ISATAP client in order to 576 give preference to IPv4 destination addresses over destination 577 addresses derived from one of the client's IPv6 sliver prefixes. 579 For example, site administrators can configure each ISATAP client 580 associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124 581 to add the prefix to its address selection policy table with a lower 582 precedence than the prefix ::ffff:0:0/96. In this way, IPv4 583 addresses are preferred over IPv6 addresses from within the same 584 sliver. The prefix could be added to each ISATAP client either 585 manually, or through an automated service such as a DHCP option 586 [I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4 587 communications to reach correspondents within the same IPv4 site 588 partition, and will use IPv6 communications to reach correspondents 589 in other partitions and/or outside of the site. 591 It should be noted that sliver prefixes longer than /64 cannot be 592 advertised for SLAAC purposes. Also, sliver prefixes longer than /64 593 do not allow for interface identifier rewriting by address 594 translators. These factors may favor the individual prefix model in 595 some deployment scenarios, while the flexibility afforded by the 596 shared prefix model may be more desirable in others. Additionally, 597 if the network is small then the shared prefix model works well. If 598 the network is large, however, a better alternative may be to deploy 599 separate ISATAP routers in each region and have each advertise their 600 own individual prefix. 602 Finally, site administrators should configure ISATAP routers to not 603 send ICMPv6 Redirect messages to inform a source client of a better 604 next hop toward the destination unless there is strong assurance that 605 the client and the next hop are within the same IPv4 site partition. 607 3.6. Loop Avoidance 609 In sites that provide IPv6 services through ISATAP with SLAAC as 610 described in this section, site administrators must take operational 611 precautions to avoid routing loops. For example, each advertising 612 ISATAP router should drop any incoming IPv6 packets that would be 613 forwarded back to itself via another of the site's advertising 614 routers. Additionally, each advertising ISATAP router should drop 615 any encapsulated packets received from another advertising router 616 that would be forwarded back to that same advertising router. This 617 corresponds to the mitigation documented in Section 3.2.3 of 618 [RFC6324], but other mitigations specified in that document can also 619 be employed. 621 Note that IPv6 packets with link-local ISATAP addresses are exempt 622 from these checks, since they cannot be forwarded by an IPv6 router 623 and may be necessary for router-to-router coordinations. 625 3.7. Interface Identifier Compatibility Considerations 627 [RFC5214] Section 6.1 specifies the setting of the "u" bit in the 628 Modified EUI-64 interface identifier format used by ISATAP. 629 Implementations that comply with the specification set the "u" bit to 630 1 when the IPv4 address is known to be globally unique, however some 631 legacy implementations unconditionally set the "u" bit to 0. 633 Implementations interpret the ISATAP interface identifier only within 634 the link to which the corresponding ISATAP prefix is assigned, hence 635 the value of the "u" bit is interpreted only within the context of an 636 on-link prefix and not within a global context. Implementers are 637 responsible for ensuring that their products are interoperable, 638 therefore implementations must make provisions for ensuring "u" bit 639 compatibility for intra-link communications. 641 Site administrators should accordingly configure access control list 642 entries and other literal representations of ISATAP interface 643 identifiers such that both values of the "u" bit are accepted. For 644 example, if the site administrator configures an access control list 645 entry that matches the prefix "fe80::0000:5efe:192.0.2.0/124" they 646 should also configure a companion list entry that matches the prefix 647 "fe80::0200:5efe:192.0.2.0/124. 649 4. Manual Configuration 651 When no autoconfiguration services are available (e.g., if there are 652 no advertising ISATAP routers present), site administrators can use 653 manual configuration to assign IPv6 addresses with ISATAP interface 654 identifiers to the ISATAP interfaces of clients. Otherwise, site 655 administrators should avoid manual configurations that would in any 656 way invalidate the assumptions of the autoconfiguration service. For 657 example, manually configured addresses may not be automatically 658 renumbered during a site-wide renumbering event, which could 659 subsequently result in communication failures. 661 5. Scaling Considerations 663 Section 3 depicts ISATAP network topologies with only two advertising 664 ISATAP routers within the site. In order to support larger numbers 665 of ISATAP clients (and/or multiple site partitions), the site can 666 deploy more advertising ISATAP routers to support load balancing and 667 generally shortest-path routing. 669 Such an arrangement requires that the advertising ISATAP routers 670 participate in an IPv6 routing protocol instance so that IPv6 671 addresses/prefixes can be mapped to the correct ISATAP router. The 672 routing protocol instance can be configured as either a full mesh 673 topology involving all advertising ISATAP routers, or as a partial 674 mesh topology with each advertising ISATAP router associating with 675 one or more companion gateways. Each such companion gateway would in 676 turn participate in a full mesh between all companion gateways. 678 6. Site Renumbering Considerations 680 Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients 681 within the site. If the site subsequently reconnects to a different 682 ISP, however, the site must renumber to use addresses derived from 683 the new IPv6 prefixes [RFC1900][RFC4192][RFC5887]. 685 For IPv6 services provided by SLAAC, site renumbering in the event of 686 a change in an ISP-served IPv6 prefix entails a simple renumbering of 687 IPv6 addresses and/or prefixes that are assigned to the ISATAP 688 interfaces of clients within the site. In some cases, filtering 689 rules (e.g., within site border firewall filtering tables) may also 690 require renumbering, but this operation can be automated and limited 691 to only one or a few administrative "touch points". 693 In order to renumber the ISATAP interfaces of clients within the site 694 using SLAAC, advertising ISATAP routers need only schedule the 695 services offered by the old ISP for deprecation and begin to 696 advertise the IPv6 prefixes provided by the new ISP. ISATAP client 697 interface address lifetimes will eventually expire, and the host will 698 renumber its interfaces with addresses derived from the new prefixes. 699 ISATAP clients should also eventually remove any deprecated SLAAC 700 prefixes from their address selection policy tables, but this action 701 is not time-critical. 703 Finally, site renumbering in the event of a change in an ISP-served 704 IPv6 prefix further entails locating and rewriting all IPv6 addresses 705 in naming services, databases, configuration files, packet filtering 706 rules, documentation, etc. If the site has published the IPv6 707 addresses of any site-internal nodes within the public Internet DNS 708 system, then the corresponding resource records will also need to be 709 updated during the renumbering operation. This can be accomplished 710 via secure dynamic updates to the DNS. 712 7. Path MTU Considerations 714 IPv6-in-IPv4 encapsulation overhead effectively reduces the size of 715 IPv6 packets that can traverse the tunnel in relation to the actual 716 Maximum Transmission Unit (MTU) of the underlying IPv4 network path 717 between the encapsulator and decapsulator. Two methods for 718 accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels 719 (i.e., the static and dynamic methods) are documented in Section 3.2 720 of [RFC4213]. 722 The static method places a "safe" upper bound on the size of IPv6 723 packets permitted to enter the tunnel, however the method can be 724 overly conservative when larger IPv4 path MTUs are available. The 725 dynamic method can accommodate much larger IPv6 packet sizes in some 726 cases, but can fail silently if the underlying IPv4 network path does 727 not return the necessary error messages. 729 This document notes that sites that include well-managed IPv4 links, 730 routers and other network middleboxes are candidates for use of the 731 dynamic MTU determination method, which may provide for a better 732 operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. 733 The dynamic MTU determination method can potentially also present a 734 larger MTU to IPv6 correspondents outside of the site, since IPv6 735 path MTU discovery is considered robust even over the wide area in 736 the public IPv6 Internet. 738 8. Alternative Approaches 740 [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in 741 enterprise networks. The ISATAP approach provides a more flexible 742 and broadly-applicable alternative, and with fewer administrative 743 touch points. 745 The tunnel broker service [RFC3053] uses point-to-point tunnels that 746 require end users to establish an explicit administrative 747 configuration of the tunnel far end, which may be outside of the 748 administrative boundaries of the site. 750 6to4 [RFC3056][RFC3068] and Teredo [RFC4380] provide "last resort" 751 unmanaged automatic tunneling services when no other means for IPv6 752 connectivity is available. These services are given lower priority 753 when the ISATAP managed service and/or native IPv6 services are 754 enabled. 756 6rd [RFC5969] enables a stateless prefix delegation capability based 757 on IPv4-embedded IPv6 prefixes, whereas ISATAP enables a stateful 758 prefix delegation capability based on native IPv6 prefixes. 760 IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] 761 were developed as the "next-generation" of ISATAP and extend to a 762 wide variety of use cases [RFC6139]. However, these technologies are 763 not yet widely implemented or deployed. 765 9. IANA Considerations 767 This document has no IANA considerations. 769 10. Security Considerations 771 In addition to the security considerations documented in [RFC5214], 772 sites that use ISATAP should take care to ensure that no routing 773 loops are enabled [RFC6324]. Additional security concerns with IP 774 tunneling are documented in [RFC6169]. 776 11. Acknowledgments 778 The following are acknowledged for their insights that helped shape 779 this work: Dmitry Anipko, Fred Baker, Brian Carpenter, Remi Despres, 780 Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel 781 Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer, Hemant Singh, 782 Mark Smith, Ole Troan, Gunter Van de Velde, ... 784 12. References 786 12.1. Normative References 788 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 789 E. Lear, "Address Allocation for Private Internets", 790 BCP 5, RFC 1918, February 1996. 792 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 793 and M. Carney, "Dynamic Host Configuration Protocol for 794 IPv6 (DHCPv6)", RFC 3315, July 2003. 796 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 797 Host Configuration Protocol (DHCP) version 6", RFC 3633, 798 December 2003. 800 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 801 for IPv6 Hosts and Routers", RFC 4213, October 2005. 803 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 804 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 805 September 2007. 807 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 808 Address Autoconfiguration", RFC 4862, September 2007. 810 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 811 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 812 March 2008. 814 12.2. Informative References 816 [I-D.ietf-6man-addr-select-opt] 817 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 818 "Distributing Address Selection Policy using DHCPv6", 819 draft-ietf-6man-addr-select-opt-01 (work in progress), 820 June 2011. 822 [I-D.templin-isupdate] 823 Templin, F., "ISATAP Updates", draft-templin-isupdate-01 824 (work in progress), July 2011. 826 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 827 RFC 1687, August 1994. 829 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 830 RFC 1900, February 1996. 832 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 833 over Non-Broadcast Multiple Access (NBMA) networks", 834 RFC 2491, January 1999. 836 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 837 Domains without Explicit Tunnels", RFC 2529, March 1999. 839 [RFC2983] Black, D., "Differentiated Services and Tunnels", 840 RFC 2983, October 2000. 842 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 843 Tunnel Broker", RFC 3053, January 2001. 845 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 846 via IPv4 Clouds", RFC 3056, February 2001. 848 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 849 RFC 3068, June 2001. 851 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 852 of Explicit Congestion Notification (ECN) to IP", 853 RFC 3168, September 2001. 855 [RFC3484] Draves, R., "Default Address Selection for Internet 856 Protocol version 6 (IPv6)", RFC 3484, February 2003. 858 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 859 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 860 September 2005. 862 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 863 Network Address Translations (NATs)", RFC 4380, 864 February 2006. 866 [RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 867 Enterprise Networks", RFC 4554, June 2006. 869 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 870 Layer (SEAL)", RFC 5320, February 2010. 872 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 873 RFC 5558, February 2010. 875 [RFC5720] Templin, F., "Routing and Addressing in Networks with 876 Global Enterprise Recursion (RANGER)", RFC 5720, 877 February 2010. 879 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 880 Still Needs Work", RFC 5887, May 2010. 882 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 883 Infrastructures (6rd) -- Protocol Specification", 884 RFC 5969, August 2010. 886 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 887 Addressing in Networks with Global Enterprise Recursion 888 (RANGER) Scenarios", RFC 6139, February 2011. 890 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 891 Concerns with IP Tunneling", RFC 6169, April 2011. 893 [RFC6179] Templin, F., "The Internet Routing Overlay Network 894 (IRON)", RFC 6179, March 2011. 896 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 897 IPv6 Automatic Tunnels: Problem Statement and Proposed 898 Mitigations", RFC 6324, August 2011. 900 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 901 RFC 6343, August 2011. 903 Author's Address 905 Fred L. Templin 906 Boeing Research & Technology 907 P.O. Box 3707 MC 7L-49 908 Seattle, WA 98124 909 USA 911 Email: fltemplin@acm.org