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