idnits 2.17.1 draft-ietf-ngtrans-interaction-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 673 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 215 instances of too long lines in the document, the longest one being 338 characters in excess of 72. ** There are 38 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 584 has weird spacing: '... rue de coutu...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BIS' is mentioned on line 128, but not defined == Missing Reference: 'BROKER' is mentioned on line 182, but not defined == Missing Reference: '6to4' is mentioned on line 490, but not defined == Unused Reference: '6TO4' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC1933' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC2767' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 571, but no explicit reference was found in the text -- No information found for draft-ietf-ngtrans-introduction-to-Ipv6-transition - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TRANSITION' == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-dstm-06 -- Possible downref: Normative reference to a draft: ref. 'DSTM' == Outdated reference: A later version (-05) exists of draft-ietf-ngtrans-bia-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-bia (ref. 'BIA') -- Possible downref: Normative reference to a draft: ref. 'BGP-TUNNEL' == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'TEREDO' ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Downref: Normative reference to an Informational RFC: RFC 3089 ** Downref: Normative reference to an Informational RFC: RFC 3142 Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Baudot 2 June 2002 France Telecom R&D 3 Expires December, 2002 G. Egeland 4 Telenor 5 C. Hahn 6 Deutsche Telekom 7 P. Kyheroinen 8 Elisa Communications 9 A. Zehl 10 Deutsche Telekom 12 Interaction of transition mechanisms 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all provisions 19 of Section 10 of RFC2026 except that the right to produce derivative works is not 20 granted. 22 This document is an Internet-Draft and is NOT offered in accordance with Section 10 23 of RFC2026, and the author does not provide the IETF with any rights other than to 24 publish as an Internet-Draft 26 Internet-Drafts are working documents of the Internet Engineering Task Force 27 (IETF), its areas, and its working groups. Note that other groups may also 28 distribute working documents as Internet-Drafts. Internet-Drafts are draft 29 documents valid for a maximum of six months and may be updated, replaced, or 30 obsoleted by other documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document discusses the interaction of transition mechanisms that can be 42 involved during the transition phase where both IPv4 and IPv6 will be concurrently 43 used. On one hand, several transition mechanisms have been defined to solve 44 particular transition issues. On the other hand, one can face multiple transition 45 issues and may have to use several transition mechanisms. 46 Since an applicability scope is attached to each transition mechanism, specifying 47 where the mechanism applies, i.e. host, domain or global, this memo aims at 48 identifying cases where multiple transition mechanisms may be involved within the 49 same scope, and what the interaction effects among them can be. 51 Table of Contents 53 0. Applicability statement 2 54 1. Introduction 2 55 2. Conventions used in this document 3 56 3. Definition of the transition phases 3 57 4. Classification of transition mechanisms 3 58 5. Interaction matrix 5 59 5.1. Interaction within the host scope 5 60 5.1.1. BIS and BIA study case 5 61 5.2. Interaction within the domain scope 6 62 5.2.1. DTSM and NAT-PT study case 6 63 5.2.2. DSTM and ISATAP study case 7 64 5.2.3. ISATAP and NAT-PT study case 8 65 5.3. Interaction within the global scope 8 66 5.3.1. Tunnel Broker and Configured Tunnel study case 8 67 5.3.2. 6to4 and Tunnel Broker study case 9 68 5.3.3. 6to4 and Configured Tunneling study case 10 69 5.4. Inter-scope interaction 10 70 5.4.1. ISATAP and 6to4 study case 10 71 6. Security Considerations 11 72 7. References 11 73 8. Authors' Addresses 12 75 0. Applicability statement 77 This document discusses interaction of transition tools that apply within a same scope, i.e. local, site or global. Thus, there is no direct relationship between the study cases analysed herein, and the transition scenario identified by ngtrans working group. Any transition tool may participate to any transition scenario, and so, the same interaction issue may be faced within different transition scenarios. 78 Hence, this document can be a companion document to all scenario documents that are to be written, and can also discuss other possible cases that may not be addressed within transition scenarios. Such a document may ensure that interaction issues are addressed with the same sharpness over the different transition scenarios. 80 1. Introduction 82 The document [TRANSITION] provides an overview of most of the transition mechanisms 83 defined within the IETF ngtrans working group. Each transition mechanism aims at 84 solving a particular transition issue, and an applicability scope specifies where 85 the tool applies: host, domain or global. During transition phase, one can face 86 multiple transition issues, and then more than one transition mechanism must be 87 deployed within a same scope. 89 The goal of this document is to focus on the interaction effects between transition 90 mechanisms that can be mutually involved. It does not intend to provide any 91 guidelines or rules on the way different transition mechanisms should be used. It 92 intends to point out, if any, potential interaction effects, one can face using 93 several transition mechanisms. 95 Section 3 defines different transition phases and clarifies where this memo applies. 97 Section 4 provides a classification of the transition mechanisms as a reminder 99 Section 5 details the interaction matrix, and discusses interaction effects. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 104 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 105 interpreted as described in RFC-2119 [ ]. 107 3. Definition of the transition phases 109 The transition phase, where both IPv4 and IPv6 will be concurrently used, is 110 commonly understood as period of time that can last years or even decades. One can 111 imagine that this early phase will look like a large IPv4 ocean with a few 112 interconnected IPv6 islands, while a later phase could look like a large IPv6 ocean 113 with a few remaining IPv4 islands. This document will only discuss interaction of 114 transition mechanisms during the early phase. 116 4. Classification of transition mechanisms 118 As reminder, the mechanisms sorted by scope, according to [TRANSITION] are listed 119 below: 121 Host scope: 123 - Dual Stack: a dual stack node has both an IPv4 and an IPv6 stack 124 available, and is then enabled to directly communicate with both IPv4 or 125 IPv6 node. A dual stack node may not have connectivity to both IPv4 and 126 IPv6 networks. 128 - Bump-In-the-Stack [BIS] can be viewed as an integrated NAT-PT, enabling 129 IPv4-only application to communicate with IPv6 only hosts. A host running 130 BIS acts as an IPv6 only host, while some of their applications are still 131 running on an IPv4 stack. 133 - Bump-in-the-API [BIA] can be compared to BIS, but acts at the API level 134 where the translation occurs. It enables IPv4-only application to 135 communicate with IPv6 only hosts. 137 Domain scope: 139 - SOCKS [RFC3089] mechanism is based on the use of SOCKS protocol, and 140 enables communication between IPv4 and IPv6 "socksified" nodes. 142 - SIIT [RFC2765] describes the method of translating an IPv4 header to an 143 IPv6 one, and vice versa. Since SIIT is a stateless method, it must be 144 applied to every packet. 146 - NAT-PT [RFC2766] translates communications between IPv4-only and IPv6-only 147 host. NAT-PT integrates a dedicated DNS application layer gateway. The 148 translation process is based on SIIT method, and a state and/or a context 149 of each communication is kept during the session lifetime. 151 - TRT [RFC3142] enables IPv6-only hosts to exchange traffic with IPv4-only 152 hosts by translating {TCP/UDP}/IPv6 to {TCP/UDP}/IPv4 and vice versa. TRT 153 acts at the transport layer. 155 - 6over4 [RFC2529] technique allows isolated IPv6 hosts to act like fully 156 functional IPv6 hosts even without direct contact with an IPv6 router. 157 6over4 uses IPv4 multicast to create a "virtual Ethernet". 159 - ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol 160 that connects IPv6 hosts and routers within IPv4 sites. ISATAP is treating 161 the site's IPv4 infrastructure as a non-broadcasting multiple access link 162 layer and tunnels the IPv6 payload in an IPv4 packet. 164 - Dual stack transition mechanism [DSTM] enables a full IPv4 end-to-end 165 communication between dual stack nodes within an IPv6-only network to an 166 IPv4-only host. DSTM is based on tunneling, using dynamic tunnel 167 interface combined with temporary IPv4 address allocation provided by 168 another way such as DHCPv6 or RPCv6 170 - Teredo [TEREDO] is a service that enables nodes located behind one or 171 several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over 172 UDP. 174 Global scope: 176 - Configured tunnel: typically this stands for manually configured tunnel where 177 information about configuration is learned "manually". 179 - Automatic tunnel: automatic tunnels are based on the use of IPv4-compatible 180 addresses from which tunnels end-point IPv4 addresses are derived. 182 - Tunnel broker [BROKER] is mainly aimed at allowing rapid connectivity to a 183 native IPv6 to an isolated dual stack host within the legacy Internet. The 184 tunnel broker system automatically manages the tunnel requests from end 185 users, thus reducing the management overhead, traditionally associated with 186 the configuration of tunnels. The tunnel broker assigns an IPv6 address to 187 the dual stack host, and returns it along with its DNS name and client 188 configuration information. 190 - 6to4 [6to4] method enables IPv6 sites to automatically connect to other IPv6 191 sites over the legacy IPv4 Internet infrastructure without specific 192 configuration. The IPv6 host, which uses this method, does not require an 193 IPv4-compatible IPv6 address, or configured tunnels. The presence of 194 firewalls in IPv4 networks does not affect the 6to4 mechanism as long as the 195 6to4 router has a globally routable IPv4 address. 197 - BGP tunnel [BGP-TUNNEL] explains how to interconnect IPv6 islands over an 198 IPv4 cloud, including the exchange of IPv6 reachability information using 199 BGP. It uses a trivial tunneling mechanism without an explicit tunnel. 201 5. Interaction matrix 203 There are currently up to 16 different transition mechanisms defined today, so that 204 a full interaction matrix would result in more or less 512 cases of possible 205 combinations of two mechanisms. 207 In order to reduce this large amount of cases, and to optimize the cases to study, 208 this documents makes the assumption that interaction between transition mechanisms 209 may only occur if they apply to the same scope and/or if they are deployed at the 210 same location. It is assumed that there is no interaction between mechanisms of 211 different scopes, unless they are located at the same place. 213 Since the host scope is composed of 3 mechanisms, the domain scope is composed of 8 214 mechanisms, and the global scope is composed of 5 mechanisms, the number of 215 possible cases is greatly reduced. Nevertheless, this document discusses the cases 216 listed below: 217 - Host scope: BIS and BIA. 218 - Domain scope: DSTM and NAT-PT, DSTM and ISATAP. 219 - Global scope: 6to4 and Tunnel Broker, Tunnel Broker and configured tunnel. 220 - Domain/Global scope: ISATAP and 6to4. 222 5.1. Interaction within the host scope 224 This section discusses interaction of two different mechanisms within the host 225 scope, and focuses on the points listed below: 226 - Impact of concurrent DNS use 227 - Concurrent use of both mechanisms by the same application 228 - Simultaneous use of both mechanisms by two different applications 230 5.1.1. BIS and BIA study case 232 BIS and BIA enable IPv4-only applications to communicate with IPv6-only hosts. They 233 are based on the principal of packet interception and translation. BIS is acting at 234 the IP layer, while BIA is acting at the API layer. Translation decision is taken 235 when the destination name resolution results in an IPv6-only end-point. Then the 236 mechanism changes the DNS answer from "AAAA" record to "A" record, and translation 237 is silently started so that the IPv4-only application will run as usual. 239 Concurrent DNS use 241 Both mechanism triggers are based on the name resolution trick, and are competing. 242 The result may be implementation dependent, but it is rather obvious that one of 243 the mechanisms will be predominant over the other one. 245 Concurrent use of both mechanisms by the same host 247 Because of the same scope of both transition mechanisms, only one mechanism per 248 host is needed. The use of both mechanisms at the same time on the same host will 249 cause confusing results because of possible double interception in the same data 250 flow. 252 Simultaneous use of both mechanisms by two different hosts 254 BIA uses the existing dual stack mechanism and a common IPv6 address to communicate 255 with other hosts via IPv6. BIS adds the IPv6 functionality to the IPv4 stack and 256 also uses common IPv6 addresses for communication with other IPv6 hosts. 257 Communication between BIS and BIA hosts will take place as it normally would occur 258 between two dual stack hosts therefore no specific issues can be raised here. 260 5.2. Interaction within the domain scope 262 This section discusses interaction of two different mechanisms within the domain 263 scope, and focuses on the points listed below: 264 - Impact of concurrent DNS use 265 - Concurrent use of both mechanisms by the same host or router 266 - Simultaneous use of both mechanism by two different hosts or routers 268 5.2.1. DTSM and NAT-PT study case 270 NAT-PT and DSTM achieve nearly the same goal, enabling communication between a host 271 connected to an IPv6-only network and IPv4-only host within the legacy Internet, 272 but in a different manner. NAT-PT assumes that one host is IPv6-only, while DSTM 273 needs a dual-stack host. NAT-PT is based on address and protocol translation, while 274 DSTM enables end-to-end IPv4 communication. 275 In a transition scenario, one can easily imagine both mechanisms being needed, for 276 example because some applications may not be ported to IPv6, while some host are 277 IPv6-only. 279 Concurrent DNS use 281 For both mechanisms, DNS use is crucial: 283 - NAT-PT needs DNS-ALG intervention for both inbound and outbound sessions. For 284 an outbound session to an IPv4-only host, the DNS-ALG will translate an 285 "AAAA" query to an "A" query, and the "A" response to an "AAAA" response. 286 The IPv4-only host will then be seen as an IPv6 host through the NAT-PT 287 gateway. In addition, NAT-PT requires that all DNS requests must pass 288 through the DNS-ALG to operate properly. The consequence of this behavior is 289 that a host within the IPv6 domain will never receive any DNS response 290 including an "A" record. 292 - A DSTM client encapsulates IPv4 into IPv6 packets for end-to-end 293 communication with an IPv4-only host. The decision of tunneling packets is 294 taken when a unique "A" record is received as name resolution of the 295 destination host. Temporary IPv4 address allocation is processed, and the 296 communication is then initiated. 298 It is obvious that within an IPv6 domain behind a NAT-PT box, a global domain 299 configuration results in directing all DNS queries and responses through a DNS-ALG, 300 and then, DSTM mechanism will never be trigged and used. 302 Concurrent use of both mechanisms by the same host 304 Because of the DNS behavior described in the section above, some extra mechanisms 305 are required to switch a DNS query through a DNS-ALG to use NAT-PT, or through 306 another way to use DSTM. 307 A single default and global configuration of an IPv6 domain behind a NAT-PT box may 308 result in the exclusive use of NAT-PT. 310 Simultaneous use of both mechanisms by two different hosts 312 Because of the DNS behavior described in the above section, a specific domain 313 configuration is needed, in order to enable the DNS traffic either to go through a 314 DNS-ALG for NAT-PT use, or to go through another gateway for DSTM use. 315 This can be achieved, for example, by using a dedicated DNS server for dual-stack 316 DSTM hosts and a dedicated DNS server for IPv6-only hosts that will use NAT-PT. 318 5.2.2. DSTM and ISATAP study case 320 DSTM aims at providing direct IPv4 connectivity to a dual stack host connected to 321 an IPv6-only network. ISATAP aims at providing IPv6 connectivity to a dual stack 322 host connected to an IPv4-only network. Since the principles are opposite, neither 323 a host running ISATAP will use DSTM mechanism, nor a DSTM host will run ISATAP. 324 However, one can deploy, for example, ISATAP on part of its legacy IPv4 domain, 325 while deploying DSTM on some IPv6-only parts of its infrastructure. 326 This study case has then to focus on the border of the domain where both TEP 327 (Tunnel End Point) and ISATAP routers can be located. 329 Concurrent DNS use 331 Neither ISATAP, nor DSTM mechanism has any specific behavior related to DNS that is 332 used as normal. DSTM uses name resolution results as a trigger for a temporary IPv4 333 address allocation through another protocol (e.g. DHCPv6 or RPCv6). 334 Both mechanisms use DNS as normal and independently so that no particular issue can 335 be raised. 337 Concurrent use of both mechanisms by the same host 339 Because of the opposite goals and network environment, one host can only run one 340 mechanism, so that concurrent use of both mechanism will never occur, and no issue 341 can be raised. 343 Simultaneous use of both mechanisms by two different hosts 345 DSTM and ISATAP tunnel packets the opposite way: respectively IPv4-in-IPv6 and 346 IPv6-in-IPv4. Both mechanisms can operate independently, even within the same 347 router, and no particular interaction issue can be raised. 349 5.2.3. ISATAP and NAT-PT study case 351 ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol that 352 connects IPv6 hosts and routers within IPv4 sites. NAT-PT enables communication 353 between an IPv6 and an IPv4 host. 355 Concurrent DNS use 357 ISATAP both have a specific IPv6 addresses and normal domain names. A dual stack 358 ISATAP host will have a routable IPv4 address which can be used to connect to other 359 IPv4 hosts. For the ISATAP host to be able to communicate with IPv4-onlyhosts 360 within a site using its IPv6 address, the DNS requests must pass through a NAT-PT 361 router with a DNS-ALG. When an IPV4 host tries to connect to an ISATAP host, it 362 will use the ISATAP host's IPv4 address if the ISATAP has an ""and an "AAAAA" 363 record defined in the DNS. If the DNS requests from the IPv4 hosts are configured 364 to go through a DNS-ALG, the connection between the two hosts will go through the 365 NAT-PT router. With such a configuration the IPv4 host will have problems 366 communicating with other IPv4-only hosts, since they have no AAAA record. Using 367 several DNS servers and letting the ISATAP hosts belong to a separate sub domain, 368 communicating with the primary DNS through a NAT-PT box, will, however, solve this. 370 Concurrent use of both mechanisms by the same host or router 372 The two mechanisms operate separately and can both be implemented in the same 373 router, i.e. ISATAP router and NAT-PT. 375 Simultaneous use of both mechanisms by two different hosts 377 As described above, an ISATAP host can communicate with other IPv4 hosts through a 378 NAT-PT box. IPv4 hosts will also be able to connect to an IPv6 ISATAP host with 379 proper configuration of DNS. 381 5.3. Interaction within the global scope 383 This section discusses interaction of two different mechanisms within the global 384 scope, and a particular focus is put on: 385 - Impact of concurrent DNS use 386 - Concurrent use of both mechanisms by the same host or router 387 - Simultaneous use of both mechanisms by two different hosts or routers 388 - 389 5.3.1. Tunnel Broker and Configured Tunnel study case 391 Configured tunnels are used to connect IPv6 islands across an IPv4 infrastructure 392 encapsulating IPv6 packets into IPv4 ones. 393 The Tunnel broker mechanism is a way to automate tunnel configuration through a 394 user interface in order to get IPv6 connectivity over an existing IPv4 395 infrastructure. All configuration steps needed to establish a tunnel are done on 396 one side by the tunnel server, which configures one side of the tunnel endpoint by 397 request. On the other side, the tunnel set-up is done by automatically generated 398 scripts that are downloaded and executed on the user PC. 399 Since the basic tunneling mechanism is used in both cases, it is assumed that no 400 particular issue can be raised. 402 Concurrent DNS use 404 There is no direct impact of the DNS on the functionality of both mechanisms. 405 The Tunnel Broker mechanism may use Dynamic DNS Update protocol to create, update 406 and delete user defined DNS records for the lifetime of the requested tunnel. Once 407 created the end user could be reached using his name. A host sitting behind a 408 configured tunnel can easily resolve the IPv6 address of the corresponding host by 409 querying the DNS. On the other side a host connected by a tunnel, provided by the 410 tunnel broker, can use the DNS without restrictions to resolve a given name. 412 Concurrent use of both mechanisms by the same host 414 Due to the equality of both mechanisms the mutual impact between them is the same 415 as between two or more configured tunnels or tunnels created by a tunnel broker 416 script. No restrictions could be seen here except for the restrictions applicable 417 by the IPv4/IPv6 stack. 419 Simultaneous use of both mechanisms by two different hosts 421 As described above no particular issue can be raised. 423 5.3.2. 6to4 and Tunnel Broker study case 425 6to4 [6to4] enables automatic tunneling between sites over an IPv4 infrastructure, 426 and provides IPv6 connectivity. In addition, 6to4 provides a globally unique IPv6 427 prefix for a site. 428 Tunnel Broker (TB) provides IPv6 connectivity to an isolated host or site within an 429 IPv4-only network, and allocates an IPv6 global address to a host or an IPv6 prefix 430 to a site. 431 Today 6to4 and Tunnel Broker are significantly deployed over the 6bone, and are 432 running independently without any noticeable interaction issues. 433 However, let's consider the following case: a Tunnel Broker allocating 6to4 434 addresses or 6to4 prefixes. 435 Allocating a 6to4 prefix to a Tunnel brokered site is somewhat confusing: A 6to4 436 mechanism can be directly deployed, because, the site owns anyway at least an IPv4 437 global address. Since its technical motivation is unclear, this case has been left 438 aside for further study. 439 Allocating 6to4 addresses may be a way of providing IPv6 connectivity without 440 owning any native IPv6 address space. This case is studied below. 442 Concurrent DNS use 444 6to4 mechanism has no impact on DNS, and Tunnel Broker manages 6to4 addresses as 445 normal IPv6 addresses. 446 No particular issues related to DNS can be raised. 448 Concurrent use of both mechanisms by the same host 450 The Tunnel Brokered host can reach all 6to4 hosts using IPv6 and all IPv6 hosts 451 behind 6to4 relay routers. It can still use IPv4 to reach IPv4 hosts. 453 Simultaneous use of both mechanisms by two different hosts 455 6to4 hosts and other IPv6 hosts, that have connection to 6to4 sites via a 6to4 456 relay router, can reach the Tunnel Brokered host through the established tunnel 457 using the 6to4 address of the dual stacked host. 459 5.3.3. 6to4 and Configured Tunneling study case 461 One can easily imagine the case of a border router running 6to4 and having 462 configured tunnels giving IPv6 connectivity to some other IPv6 only sites. 464 Concurrent DNS use 466 Since, neither 6to4 mechanism, nor configured tunnel have any impact on DNS, no 467 particular issue can be raised. 469 Concurrent use of both mechanisms by the same host or router 471 6to4 mechanism is solicited for communications with other external 6to4 hosts, 472 while configured tunnel are used for communications with hosts belonging to other 473 IPv6 sites. Within a given border router, both mechanisms can run independently, 474 and no particular interaction issues can be raised. 476 Simultaneous use of both mechanisms by two different hosts or routers 478 As described above no particular issue can be raised. 480 5.4. Inter-scope interaction 482 5.4.1. ISATAP and 6to4 study case 484 ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol that 485 connects IPv6 hosts and routers within IPv4 sites. ISATAP treats the site's IPv4 486 infrastructure as a non-broadcasting multiple access link layer and tunnels the 487 IPv6 payload in an IPv4 packet. ISATAP provides a 64-bit interface identifier field 488 with an embedded IPv4 address that is used for tunneling between other ISATAP 489 hosts/routers within a site. 490 6to4 [6to4] enables automatic tunneling between sites over an IPv4 infrastructure. 491 By using a globally routable IPv4 address, 6to4 provides a globally unique IPv6 492 prefix for a site. 493 In this case, ISATAP and 6to4 are combined to provide IPv6 connectivity to a host, 494 which is connected to an internal IPv4 infrastructure as well as to an external 495 IPv4 infrastructure. 497 Concurrent DNS use 499 6to4 and ISATAP both have specific IPv6 addresses and normal domain names. 500 Communication with a DNS server will take place as normal. 502 Concurrent use of both mechanisms by the same host or router 504 A router that implements both ISATAP and 6to4 will be able to communicate with both 505 ISATAP hosts within the site and other 6to4 sites. The two mechanisms use IPv6-in- 506 IPv4 encapsulation, but operate independently of each other since an ISATAP router 507 tunnels packets to a host while a 6to4 router tunnels traffic to other 6to4 sites. 509 Simultaneous use of both mechanisms by two different hosts or routers 511 An ISATAP host communicates with other IPv6 hosts either directly or via an ISATAP 512 router. A host using a 6to4 address will communicate with other 6to4 sites via its 513 6to4 router and with other IPv6 hosts via a 6to4 gateway. If a valid IPv6 route 514 between the ISATAP router and the 6to4 gateway exists, communication between the 515 connected hosts takes place as normal. 517 6. Security Considerations 519 Section explains briefly that security considerations are out of the scope of the 520 document, and that almost every single transition mechanism includes a section 521 dedicated to its own security. 523 7. References 525 [TRANSITION] W. Bielmont, A. Durand, D. Finkerson, A. Hazeltine, M. Kaat, T. 526 Larder, R. van der Pol, Y. Sekiya, H. Steeman, G.Tsirtsis, An 527 overview of the introduction of Ipv6 transition in the Internet, 528 draft-ietf-ngtrans-introduction-to-Ipv6-transition-07.txt, July 529 2001, (work in progress). 531 [6TO4] B. Carpenter, K. Moore, Connection of IPv6 Domains via 532 IPv4 Clouds, RFC 3056, February 2001. 534 [DSTM] J. Bound, L. Toutain, O. Medina, F. Dupont,H. Affifi, A. Durand, 535 "Dual Stack Transition Mechanism (DSTM)", draft-ietf-ngtrans-dstm- 536 06.txt, January 2002, work in progress. 538 [BIA] S. Lee, M. Shin, Y. Kim, E. Nordmark, A. Durand, "Dual stack host 539 using BUMP-in-the-API",draft-ietf-ngtrans-bia-02.txt, January 2002, 540 work in progress. 542 [BGP-TUNNEL] J. De Clercq, G. Gastaud, Y Nguyen, D. Ooms, S. Prevost, F. Le 543 Faucheur, "Connecting IPv6 Islands across IPv4 Clouds with BGP", 544 draft-ietf-ngtrans-bgp-tunnel-04.txt, January 2002, work in 545 progress. 547 [ISATAP] F. Templin, T. Gleeson, M. Talwar, D. Thaler, "Intra-Site Automatic 548 Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap- 549 03.txt, January 2002, work in progress. 551 [TEREDO] C. Huitema, "Teredo : Tunneling IPv6 over UDP through NATs", 552 February 2002, work in progress. 554 [RFC1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for 555 IPv6 Hosts and Routers", RFC 1933, April 1996. 557 [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 558 Domains without Explicit Tunnels", RFC2529, March 1999. 560 [RFC2765] E. Nordmark, "Stateless IP/ICMP Translator", 561 RFC 2765, February 2000. 563 [RFC2766] G. Tsirtsis, P. Srisuresh, 564 "Network Address Translation - Protocol Translation 565 (NAT-PT)", RFC 2766, February 2000. 567 [RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 568 using the Bump-in-the-Stack technique", 569 RFC 2767, February 2000. 571 [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 572 Tunnel Broker", RFC3053, January 2001 574 [RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 gateway mechanism", RFC3089, 575 April 2001. 577 [RFC3142] J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport 578 relay translator", RFC3142, June 2001. 580 8. Authors' Addresses 582 Alain Baudot 583 France Telecom R&D 584 42, rue de coutures - BP 6243 585 14066 Caen cedex 4 586 France 587 E-mail : alain.baudot@francetelecom.com 589 Geir Egeland 590 Telenor Research and Development 591 PO BOX 83 592 N-2027 Kjeller 593 Office: Instituttveien 23 594 E-mail: geir.egeland@telenor.com 596 Christian Hahn 597 Deutsche Telekom 598 T-Nova Berkom 599 Goslarer Ufer 35 600 10589 Berlin 601 Germany 602 E-mail: HahnC@t-systems.com 604 Pasi Kyher�inen 605 Elisa Communications 606 Kutomotie 14, Helsinki 607 P.O.Box 40, FIN-00061 ELISA 608 Finland 609 E-mail : pasi.kyheroinen@rc.elisa.fi 611 Andre' Zehl 612 Deutsche Telekom 613 T-Nova Berkom 614 Goslarer Ufer 35 615 10589 Berlin 616 Germany 617 E-mail: andre.zehl@telekom.com 619 Full Copyright Statement 621 "Copyright (C) The Internet Society (<2002>). All Rights Reserved. 623 This document and translations of it may be copied and furnished to others, and 624 derivative works that comment on or otherwise explain it or assist its 625 implementation may be prepared, copied, published and distributed, in whole or in 626 part, without restriction of any kind, provided that the above copyright notice and 627 this paragraph are included on all such copies and derivative works. However, this 628 document itself may not be modified in any way, such as by removing the copyright 629 notice or references to the Internet Society or other Internet organizations, 630 except as needed for the purpose of developing Internet standards in which case the 631 procedures for copyrights defined in the Internet Standards process must be 632 followed, or as required to translate it into languages other than English. 634 The limited permissions granted above are perpetual and will not be revoked by the 635 Internet Society or its successors or assigns. 637 This document and the information contained herein is provided on an "AS IS" basis 638 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 639 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 640 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 641 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.