idnits 2.17.1 draft-templin-isupdate-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2011) is 4680 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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 (-12) exists of draft-templin-aero-01 == Outdated reference: A later version (-19) exists of draft-templin-v6ops-isops-12 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 5 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: Standards Track July 5, 2011 5 Expires: January 6, 2012 7 ISATAP Updates 8 draft-templin-isupdate-01.txt 10 Abstract 12 Many end user sites in the Internet today still have predominantly 13 IPv4 internal infrastructures. These sites range in size from small 14 home/office networks to large corporate enterprise networks, but 15 share the commonality that IPv4 continues to provide satisfactory 16 internal routing and addressing services for most applications. As 17 more and more IPv6-only services are deployed in the Internet, 18 however, end user devices within such sites will increasingly require 19 at least basic IPv6 functionality for external access. It is also 20 expected that more and more IPv6-only devices will be deployed within 21 the site over time. This document therefore discusses updates to the 22 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to better 23 accommodate these needs. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 6, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. ISATAP Updates . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. DHCPv6 Services . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 5 63 3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 5 64 3.3. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 6 65 3.4. Reference Operational Scenario - DHCPv6 Model . . . . . . 6 66 3.5. DHCPv6 Site Administration Guidance . . . . . . . . . . . 9 67 3.6. On-Demand Dynamic Routing for DHCP . . . . . . . . . . . . 10 68 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 11 69 4. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 End user sites in the Internet today currently use IPv4 routing and 81 addressing internally for core operating functions such as web 82 browsing, filesharing, network printing, e-mail, teleconferencing and 83 numerous other site-internal networking services. Such sites 84 typically have an abundance of public or private IPv4 addresses for 85 internal networking, and are separated from the public Internet by 86 firewalls, packet filtering gateways, proxies, address translators 87 and other site border demarcation devices. To date, such sites have 88 had little incentive to enable IPv6 services internally [RFC1687]. 90 End-user sites that currently use IPv4 services internally come in 91 endless sizes and varieties. For example, a home network behind a 92 Network Address Translator (NAT) may consist of a single link 93 supporting a few laptops, printers etc. As a larger example, a small 94 business may consist of one or a few offices with several networks 95 connecting considerably larger numbers of computers, routers, 96 handheld devices, printers, faxes, etc. Moving further up the scale, 97 large banks, restaurants, major retailers, large corporations, etc. 98 may consist of hundreds or thousands of branches worldwide that are 99 tied together in a complex global enterprise network. Additional 100 examples include personal-area networks, mobile vehicular networks, 101 disaster relief networks, tactical military networks, and various 102 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 103 discussed in RANGERS[RFC6139]. 105 With the proliferation of IPv6 devices in the public Internet, 106 however, existing IPv4 sites will increasingly require a means for 107 enabling IPv6 services so that hosts within the site can communicate 108 with IPv6-only correspondents. Such services must be deployable with 109 minimal configuration, and in a fashion that will not cause 110 disruptions to existing IPv4 services. The Intra-Site Automatic 111 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 112 use service that sites can deploy in the near term to meet these 113 requirements, as discussed in [I-D.templin-v6ops-isops]. However, 114 the ISATAP base specification has several fundamental limitations 115 that restrict its applicability. 117 For example, the base specification does not allow for router-to- 118 router tunneling and also does not support DHCPv6-based address 119 and/or prefix delegation services [RFC3315][RFC3633]. The base 120 specification furthermore does not permit the assignment of non 121 ISATAP-format addresses of any kind to the ISATAP interface. 122 Finally, the base specification provides no means for address 123 selection preference of IPv4 over ISATAP for communications within 124 the same site. This document therefore specifies updates to the base 125 specification to address these deficiencies. 127 2. ISATAP Updates 129 The base ISATAP model supports two basic node types - namely, 130 advertising ISATAP routers and ISATAP hosts. Advertising ISATAP 131 routers configure their site-facing ISATAP interfaces as advertising 132 router interfaces (see: [RFC4861], Section 6.2.2). ISATAP hosts 133 configure their site-facing ISATAP interfaces as simple host 134 interfaces and also coordinate their autoconfiguration operations 135 with advertising ISATAP routers. 137 This document introduces a third node type known as "non-advertising 138 ISATAP routers". Non-advertising ISATAP routers configure their 139 site-facing ISATAP interfaces as non-advertising router interfaces 140 and obtain IPv6 addresses/prefixes via manual or automatic 141 configuration arrangements with advertising ISATAP routers. Non- 142 advertising ISATAP routers connect IPv6 networks to the ISATAP link, 143 and can therefore support a router-to-router tunneling mode not 144 supported under the base specification. 146 To support this router-to-router tunneling (and also to support the 147 assignment of non ISATAP-format addresses on ISATAP interfaces) 148 ISATAP nodes add an update to the source address verification checks 149 specified in Section 7.3 of [RFC5214]. Namely, the node also 150 considers the outer IPv4 source address correct for the inner IPv6 151 source address if: 153 o a forwarding table entry exists that lists the packet's IPv4 154 source address as the link-layer address corresponding to the 155 inner IPv6 source address via the ISATAP interface. 157 The base ISATAP model further does not specify any IPv6 multicast 158 mappings. This precludes the use of services such as DHCPv6 which 159 require a link-scoped IPv6 multicasting service. To support DHCPv6 160 services, ISATAP hosts and non-advertising ISATAP routers that 161 observe this specification map the IPv6 162 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 163 the IPv4 address of an advertising ISATAP router. Advertising ISATAP 164 routers in turn configure a DHCPv6 server or relay function, and 165 accept DHCPv6 messages sent by clients using this mapping. The 166 advertising router also maintains IPv6 forwarding table entries that 167 list the IPv4 address of the client as the link-layer address of any 168 delegated IPv6 addresses or prefixes. 170 Finally, this document updates the address selection policies of the 171 base specification as follows. For communications between two nodes 172 whose IPv6 addresses are covered by the same IPv6 prefix advertised 173 in Router Advertisements (RAs) on an ISATAP interface, prefer IPv4 174 over IPv6 if the L bit in the Prefix Information Option (PIO) is set 175 to 0. 177 Using these updates, a much richer ISATAP service model is made 178 possible. The following two sections describe the new modes of 179 operation that are enabled by the updates. 181 3. DHCPv6 Services 183 Whether or not advertising ISATAP routers make stateless IPv6 184 services available using StateLess Address AutoConfiguration (SLAAC), 185 they can also provide managed IPv6 services to ISATAP clients (i.e., 186 both hosts and non-advertising ISATAP routers) using DHCPv6. Any 187 addresses/prefixes obtained via DHCPv6 are distinct from any IPv6 188 prefixes advertised on the ISATAP interface for SLAAC purposes, 189 however. 191 The following sections discuss operational considerations for 192 enabling ISATAP DHCPv6 services within predominantly IPv4 sites. 194 3.1. Advertising ISATAP Router Behavior 196 Advertising ISATAP routers that support DHCPv6 services send RA 197 messages in response to Router Solicitation (RS) messages received on 198 an advertising ISATAP interface. Advertising ISATAP routers also 199 configure either a DHCPv6 relay or server function to service DHCPv6 200 requests received from ISATAP clients. 202 3.2. ISATAP Host Behavior 204 ISATAP hosts send RS messages to obtain RA messages from an 205 advertising ISATAP router. When the DHCPv6 service is available, the 206 host can acquire IPv6 addresses through the use of DHCPv6 stateful 207 address autoconfiguration [RFC3315] whether or not IPv6 prefixes for 208 SLAAC are advertised. To acquire addresses, the host performs 209 standard DHCPv6 exchanges while mapping the IPv6 210 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 211 the IPv4 address of an advertising ISATAP router. 213 After the host receives IPv6 addresses, it assigns them to its ISATAP 214 interface and forwards any of its outbound IPv6 packets via the 215 advertising router as a default router. The advertising router in 216 turn maintains IPv6 forwarding table entries that list the IPv4 217 address of the host as the link-layer address of the delegated IPv6 218 addresses. Note that IPv6 addresses acquired from DHCPv6 therefore 219 need not be ISATAP addresses, i.e., even though the addresses are 220 assigned to the ISATAP interface. 222 3.3. Non-Advertising ISATAP Router Behavior 224 Non-advertising ISATAP routers can acquire IPv6 prefixes through the 225 use of DHCPv6 Prefix Delegation [RFC3633] via an advertising router 226 in the same fashion as described above for host-based DHCPv6 stateful 227 address autoconfiguration. The advertising router in turn maintains 228 IPv6 forwarding table entries that list the IPv4 address of the non- 229 advertising router as the link-layer address of the next hop toward 230 the delegated IPv6 prefixes. 232 In many use case scenarios (e.g., small enterprise networks, MANETs, 233 etc.), advertising and non-advertising ISATAP routers can engage in a 234 proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) 235 over their ISATAP interfaces so that IPv6 routing/forwarding tables 236 can be populated and standard IPv6 forwarding between ISATAP routers 237 can be used. In other scenarios (e.g., large enterprise networks, 238 highly mobile MANETs, etc.), this might be impractical dues to 239 scaling issues. When a proactive dynamic routing protocol cannot be 240 used, non-advertising ISATAP routers send RS messages to obtain RA 241 messages from an advertising ISATAP router, i.e., they act as "hosts" 242 on their non-advertising ISATAP interfaces. 244 After the non-advertising ISATAP router acquires IPv6 prefixes, it 245 can sub-delegate them to routers and links within its attached IPv6 246 edge networks, then can forward any outbound IPv6 packets coming from 247 its edge networks via other ISATAP nodes on the link. 249 3.4. Reference Operational Scenario - DHCPv6 Model 251 Figure 1 depicts a reference ISATAP network topology that uses 252 DHCPv6. The scenario shows two advertising ISATAP routers ('A', 253 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host 254 ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical 255 deployment configuration: 257 .-(::::::::) 2001:db8:3::1 258 .-(::: IPv6 :::)-. +-------------+ 259 (:::: Internet ::::) | IPv6 Host H | 260 `-(::::::::::::)-' +-------------+ 261 `-(::::::)-' 262 ,~~~~~~~~~~~~~~~~~, 263 ,----|companion gateway|--. 264 / '~~~~~~~~~~~~~~~~~' : 265 / |. 266 ,-' `. 267 ; +------------+ +------------+ ) 268 : | Router A | | Router B | / 269 : | (isatap) | | (isatap) | : fe80::*192.0.2.4 270 : | 192.0.2.1 | | 192.0.2.1 | ; 2001:db8:2::1 271 + +------------+ +------------+ \ +--------------+ 272 fe80::*:192.0.2.1 fe80::*:192.0.2.1 | (isatap) | 273 | ; | Host G | 274 : IPv4 Site -+-' +--------------+ 275 `-. (PRL: 192.0.2.1) .) 276 \ _) 277 `-----+--------)----+'----' 278 fe80::*:192.0.2.2 fe80::*:192.0.2.3 .-. 279 +--------------+ +--------------+ ,-( _)-. 280 | (isatap) | | (isatap) | .-(_ IPv6 )-. 281 | Router C | | Router E |--(__Edge Network ) 282 +--------------+ +--------------+ `-(______)-' 283 2001:db8:0::/48 2001:db8:1::/48 | 284 | 2001:db8:1::1 285 .-. +-------------+ 286 ,-( _)-. 2001:db8:0::1 | IPv6 Host F | 287 .-(_ IPv6 )-. +-------------+ +-------------+ 288 (__Edge Network )--| IPv6 Host D | 289 `-(______)-' +-------------+ 291 (* == "5efe") 293 Figure 1: Reference ISATAP Network Topology using DHCPv6 295 In Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 296 site connect to the IPv6 Internet via a companion gateway. (Note 297 that the routers may instead connect to the IPv6 Internet directly as 298 shown in [I-D.templin-v6ops-isops]. 300 Advertising ISATAP routers 'A' and 'B' both configure the IPv4 301 anycast address 192.0.2.1 on a site-interior IPv4 interface, and 302 configure an advertising ISATAP interface with link-local ISATAP 303 address fe80::5efe:192.0.2.1. The site administrator then places the 304 single IPv4 address 192.0.2.1 in the Potential Router List (PRL) for 305 the site. 'A' and 'B' then both advertise the anycast address/prefix 306 into the site's IPv4 routing system so that ISATAP clients can locate 307 the router that is topologically closest. (Note: advertising ISATAP 308 routers can instead use individual IPv4 unicast addresses instead of 309 a shared IPv4 anycast address. In that case, the PRL may contain 310 multiple IPv4 addresses of advertising routers.) 312 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 313 networks and also connects to the site via an IPv4 interface with 314 address 192.0.2.2, but it does not advertise the site's IPv4 anycast 315 address/prefix. 'C' next configures a non-advertising ISATAP router 316 interface with link-local ISATAP address fe80::5efe:192.0.2.2, then 317 discovers router 'A' via an IPv6-in-IPv4 encapsulated RS/RA exchange. 318 'C' next receives the IPv6 prefix 2001:db8:0::/48 through a DHCPv6 319 prefix delegation exchange via 'A', then engages in an IPv6 routing 320 protocol over its ISATAP interface and announces the delegated IPv6 321 prefix. 'C' finally sub-delegates the prefix to its attached edge 322 networks, where IPv6 host 'D' autoconfigures the address 323 2001:db8:0::1. 325 Non-advertising ISATAP router 'E' connects to the site, configures 326 its ISATAP interface, performs an RS/RA exchange, receives a DHCPv6 327 prefix delegation, and engages in the IPv6 routing protocol the same 328 as for 'C'. In particular, 'E' configures the IPv4 address 192.0.2.3 329 and the link-local ISATAP address fe80::5efe:192.0.2.3. 'E' then 330 receives the delegated IPv6 prefix 2001:db8:1::/48 and sub-delegates 331 the prefix to its attached edge networks, where IPv6 host 'F' 332 autoconfigures IPv6 address 2001:db8:1::1. 334 ISATAP host 'G' connects to the site via an IPv4 interface with 335 address 192.0.2.4, and also configures an ISATAP host interface with 336 link-local ISATAP address fe80::5efe:192.0.2.4 over the IPv4 337 interface. 'G' next performs an anycast RS/RA exchange to discover 338 'B" and configure a default IPv6 route with next-hop address fe80:: 339 5efe:192.0.2.1. 'G' then receives the IPv6 address 2001:db8:2::1 340 from a DHCPv6 address configuration exchange via 'B'; it then assigns 341 the address to the ISATAP interface but does not assign a non-link- 342 local IPv6 prefix to the interface. 344 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 345 ISATAP domain. 'H' configures its IPv6 interface in a manner 346 specific to its attached IPv6 link, and autoconfigures the IPv6 347 address 2001:db8:3::1. 349 Following this autoconfiguration, when host 'D' has an IPv6 packet to 350 send to host 'F', it prepares the packet with source address 2001: 351 db8:0::1 and destination address 2001:db8:1::1, then sends the packet 352 into the edge network where IPv6 forwarding will eventually convey it 353 to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to forward 354 the packet to router 'E', since it has discovered a route to 2001: 355 db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP 356 interface. Router 'E' finally sends the packet into the edge network 357 where IPv6 forwarding will eventually convey it to host 'F'. 359 In a second scenario, when 'D' has a packet to send to ISATAP host 360 'G', it prepares the packet with source address 2001:db8:0::1 and 361 destination address 2001:db8:2::1, then sends the packet into the 362 edge network where it will eventually be forwarded to router 'C' the 363 same as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward 364 the packet to router 'A' (i.e., 'C's default router), which in turn 365 forwards the packet to 'G'. Note that this operation entails two 366 hops across the ISATAP link (i.e., one from 'C' to 'A', and a second 367 from 'A' to 'G'). If 'G' also participates in the dynamic IPv6 368 routing protocol, however, 'C' could instead forward the packet 369 directly to 'G' without involving 'A'. 371 In a third scenario, when 'D' has a packet to send to host 'H' in the 372 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 373 then forwards the packet to 'A', which forwards the packet into the 374 IPv6 Internet. 376 In a final scenario, when 'G' has a packet to send to host 'H' in the 377 IPv6 Internet, the packet is forwarded directly to 'B', which 378 forwards the packet into the IPv6 Internet. 380 3.5. DHCPv6 Site Administration Guidance 382 Site administrators configure advertising ISATAP routers that also 383 support the DHCPv6 relay/server function to send RA messages with the 384 M flag set to 1 as an indication to clients that the stateful DHCPv6 385 address autoconfiguration services area available. If stateless 386 DHCPv6 services are also available, the RA messages also set the O 387 flag to 1. 389 Gateways and packet filtering devices of various forms are often 390 deployed in order to divide the site into separate partitions. 391 Although the purely DHCPv6 model does not involve the advertisement 392 of non-link-local IPv6 prefixes on ISATAP interfaces, alignment of 393 IPv6 prefixes used for DHCPv6 address assignment with IPv4 site 394 partitions is still recommended so that ISATAP clients can prefer 395 native IPv4 communications over ISATAP IPv6 services for 396 correspondents within their contiguous IPv4 partition. 398 For example, if the site is assigned the aggregate prefix 2001:db8: 399 0::/48, then the site administrators can assign the more-specific 400 prefixes 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, 401 etc. to the different IPv4 partitions within the site. The 402 administrators can then institute a policy that prefers native IPv4 403 addresses for communications between clients covered by the same /64 404 prefix. 406 Site administrators can implement this policy implicitly by 407 configuring advertising ISATAP routers to advertise each /64 prefix 408 with both the A and L flags set to 0 as an indication that IPv4 409 should be preferred over IPv6 destinations that configure addresses 410 from the same prefix. Site administrators can instead (or in 411 addition) implement address selection policy rules [RFC3484] through 412 explicit configurations in each ISATAP client. 414 For example, each ISATAP client associated with the prefix 2001:db8: 415 0:0::/64 can add the prefix to its address selection policy table 416 with a lower precedence than the prefix ::ffff:0:0/96. In this way, 417 IPv4 addresses are preferred over IPv6 addresses from within the same 418 /64 prefix. The prefix could be added to each ISATAP client either 419 manually, or through an automated service such as a DHCP option 420 [I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4 421 communications to reach correspondents within the same IPv4 site 422 partition, and will use IPv6 communications to reach correspondents 423 in other partitions and/or outside of the site. 425 When the PRL includes an anycast address, the client may be directed 426 to a first DHCPv6 relay/server in initial message exchanges and to a 427 different relay/server in subsequent exchanges. In order to address 428 this uncertainty, site administrators should configure DHCPv6 servers 429 to include a Server Unicast option so that clients can remain 430 associated with the same server that was reached during the initial 431 exchange. (Alternatively, the administrator could arrange for the 432 site's DHCPv6 servers to maintain a distributed database of client 433 bindings.) 435 Finally, site administrators should configure ISATAP routers to not 436 send ICMPv6 Redirect messages to inform a source client of a better 437 next hop toward the destination unless there is strong assurance that 438 the client and the next hop are within the same IPv4 site partition. 440 3.6. On-Demand Dynamic Routing for DHCP 442 With respect to the reference operational scenarios depicted in 443 Figure 1, there may be use cases in which a proactive dynamic IPv6 444 routing protocol cannot be used. For example, in large enterprise 445 network deployments it would be impractical for all ISATAP routers to 446 engage in a common routing protocol instance due to scaling 447 considerations. 449 In those cases, an on-demand routing capability can be enabled in 450 which ISATAP nodes send initial packets via an advertising ISATAP 451 router and receive redirection messages back. For example, when a 452 non-advertising ISATAP router 'C' has a packet to send to a host 453 located behind non-advertising ISATAP router 'E', it can send the 454 initial packets via advertising router 'A' which will return 455 redirection messages to inform 'C' that 'E' is a better first hop. 456 Protocol details for this redirection procedure (including a means 457 for detecting whether the direct path is usable) are specified in 458 [I-D.templin-aero]. 460 3.7. Loop Avoidance 462 In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6 463 prefixes are assigned to ISATAP router interfaces. Therefore, an 464 ISATAP router cannot mistake another router for an ISATAP host due to 465 an address that matches an on-link prefix. This corresponds to the 466 mitigation documented in Section 3.2.4 of 467 [I-D.ietf-v6ops-tunnel-loops]. 469 Any routing loops introduced in the DHCPv6 scenario would therefore 470 be due to a misconfiguration in IPv6 routing the same as for any IPv6 471 router, and hence are out of scope for this document. 473 4. Manual Configuration 475 In addition to any SLAAC services and DHCPv6 services, when the 476 updates in this document are employed site administrators can use 477 manual configuration to assign non-ISATAP IPv6 addresses to the 478 ISATAP interfaces of client end systems. Site administrators can 479 also use manual configuration to assign IPv6 prefixes to non- 480 advertising ISATAP routers instead of (or in addition to) using 481 DHCPv6 prefix delegation. 483 The IPv6 prefixes used for manual configuration must be distinct from 484 any prefixes used for SLAAC, however they may overlap with the 485 prefixes used for DHCPv6 as long as there is administrative assurance 486 that the same IPv6 addresses/prefixes will not be delegated by both 487 DHCPv6 and manual configuration. The manual configuration scenarios 488 and routing considerations are otherwise the same as discussed for 489 DHCPv6 in Section 4. 491 When manually configured IPv6 addresses/prefixes are used, the 492 prefixes must be covered by a shorter IPv6 prefix advertised into the 493 IPv6 routing system by one or more advertising ISATAP routers. The 494 advertising routers must further maintain forwarding table entries 495 that associate the addresses/prefixes with the ISATAP clients to 496 which the addresses/prefixes are delegated, i.e., the same as for 497 DHCPv6. 499 5. IANA Considerations 501 This document has no IANA considerations. 503 6. Security Considerations 505 In addition to the security considerations documented in [RFC5214], 506 sites that use ISATAP should take care to ensure that no routing 507 loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security 508 concerns with IP tunneling are documented in [RFC6169]. 510 7. Acknowledgments 512 The following are acknowledged for their insights that helped shape 513 this work: Dmitry Anipko, Fred Baker, Brian Carpenter, Remi Despres, 514 Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel 515 Jaeggli, John Mann, Gabi Nakibly, Christoper Palmer, Hemant Singh, 516 Mark Smith, Dave Thaler, Ole Troan, Gunter Van de Velde, ... 518 8. References 520 8.1. Normative References 522 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 523 and M. Carney, "Dynamic Host Configuration Protocol for 524 IPv6 (DHCPv6)", RFC 3315, July 2003. 526 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 527 Host Configuration Protocol (DHCP) version 6", RFC 3633, 528 December 2003. 530 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 531 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 532 September 2007. 534 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 535 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 536 March 2008. 538 8.2. Informative References 540 [I-D.ietf-6man-addr-select-opt] 541 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 542 "Distributing Address Selection Policy using DHCPv6", 543 draft-ietf-6man-addr-select-opt-01 (work in progress), 544 June 2011. 546 [I-D.ietf-v6ops-tunnel-loops] 547 Nakibly, G. and F. Templin, "Routing Loop Attack using 548 IPv6 Automatic Tunnels: Problem Statement and Proposed 549 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 550 progress), May 2011. 552 [I-D.templin-aero] 553 Templin, F., "Asymmetric Extended Route Optimization 554 (AERO)", draft-templin-aero-01 (work in progress), 555 June 2011. 557 [I-D.templin-v6ops-isops] 558 Templin, F., "Operational Guidance for IPv6 Deployment in 559 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-12 560 (work in progress), July 2011. 562 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 563 RFC 1687, August 1994. 565 [RFC3484] Draves, R., "Default Address Selection for Internet 566 Protocol version 6 (IPv6)", RFC 3484, February 2003. 568 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 569 Addressing in Networks with Global Enterprise Recursion 570 (RANGER) Scenarios", RFC 6139, February 2011. 572 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 573 Concerns with IP Tunneling", RFC 6169, April 2011. 575 Author's Address 577 Fred L. Templin 578 Boeing Research & Technology 579 P.O. Box 3707 MC 7L-49 580 Seattle, WA 98124 581 USA 583 Email: fltemplin@acm.org