idnits 2.17.1 draft-ietf-softwire-problem-statement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1055. 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 Copyright Line does not match the current year -- 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.) -- The document date (Mar 19, 2007) is 6246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipsec-tunnels' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'I-D.palet-v6ops-solution-tun-auto-disc' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'RFC4365' is defined on line 1002, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-04 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipsec-tunnels-01 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dawkins, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational Mar 19, 2007 5 Expires: September 20, 2007 7 Softwire Problem Statement 8 draft-ietf-softwire-problem-statement-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 20, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document captures the problem statement for the Softwires 42 Working Group, which is developing standards for the discovery, 43 control, and encapsulation methods for connecting IPv4 networks 44 across IPv6-only networks as well as IPv6 networks across IPv4-only 45 networks. The standards will encourage multiple, inter-operable 46 vendor implementations by identifying, and extending where necessary, 47 existing standard protocols to resolve a selected set of "IPv4/IPv6" 48 and "IPv6/IPv4" transition problems. This document describes the 49 specific problems ("Hubs and Spokes" and "Mesh") that will be solved 50 by the standards developed by the Softwires Working Group. Some 51 requirements (and non-requirements) are also identified to better 52 describe the specific problem scope. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 7 59 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 60 2.2. Non-upgradable CPE router . . . . . . . . . . . . . . . . 10 61 2.3. Network Address Translation (NAT) and Port Address 62 Translation (PAT) . . . . . . . . . . . . . . . . . . . . 11 63 2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 11 64 2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 12 65 2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 12 66 2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 13 67 2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 70 2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.11.1. Authentication, Authorization and Accounting . . . . 13 72 2.11.2. Privacy, Integrity, and Replay protection . . . . . . 14 73 2.12. Operations and Management (O&M) . . . . . . . . . . . . . 14 74 2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 14 75 3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 3.3. Persistence, Discovery and Setup Time . . . . . . . . . . 17 79 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 80 3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 18 81 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 6. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . . 21 85 7. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 22 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 8.2. Contributors . . . . . . . . . . . . . . . . . . . . . . . 25 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 Intellectual Property and Copyright Statements . . . . . . . . . . 29 95 1. Introduction 97 The Softwires Working Group is specifying the standardization of 98 discovery, control and encapsulation methods for connecting IPv4 99 networks across IPv6-only networks and IPv6 networks across IPv4-only 100 networks in a way that will encourage multiple, inter-operable vendor 101 implementations. This document describes the specific problems 102 ("Hubs and Spokes" and "Mesh") that will be solved by the standards 103 developed by the Softwires Working Group. Some requirements (and 104 non-requirements) are also identified to better describe the specific 105 problem scope. A few generic assumptions are listed up front: 107 o Local Area Networks will often support both protocol families in 108 order to accommodate both IPv4-only and IPv6-only applications, in 109 addition to dual-stack applications. Global reachability requires 110 the establishment of softwire connectivity to transit across 111 portions of the network that do not support both address families. 112 Wide area networks that support one or both address families may 113 be separated by transit networks that do not support all address 114 families. Softwire connectivity is necessary to establish global 115 reachability of both address families. 117 o Softwires are to be used in IP-based networks to forward both 118 unicast and multicast traffic. 120 o Softwires are assumed to be long-lived in nature. 122 o Although Softwires are long-lived, the setup time of a softwire is 123 expected to be a very small fraction of the total time required 124 for startup of the Customer Premise Equipment (CPE)/Address Family 125 Border Router (AFBR). 127 o The nodes that actually initiate softwires should support dual- 128 stack (IPv4 and IPv6) functionality. 130 o The goal of this effort is to reuse or extending existing 131 technology. The 'time-to-market' requirement for solutions to the 132 stated problems is very strict and existing, deployed technology 133 must be very strongly considered in our solution selection. 135 The solution to the stated problem should address the following 136 points: 138 o Relation of the softwire protocols to other host mechanisms in the 139 same layer of the network stack. Examples of mechanisms to 140 consider are tunneling mechanisms, VPNs, mobility (SHIM6,... 142 o Operational brittelness introduced by softwire, e.g. potential 143 single point of failure or difficulties to deploy redundant 144 systems. 146 o Effects of softwires on the transport layer. Issue like packet 147 losses, congestion control and handling of QoS reservation and 148 usage of on-path protocols such as RSVP. 150 The history of IPv4 and IPv6 transition strategies at the IETF is a 151 very long and complex. Here we list out some steps we have taken to 152 further the effort and it has lead to the creation of this document 153 and a few 'working rules' for us to accomplish our work: 155 o At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF 156 meeting, attendees from several operators requested a very tight 157 timeframe for delivery of a solution, based on time-to-market 158 considerations. This problem statement is narrowly scoped to 159 accommodate near-term deployment. 161 o At the Paris Softwires interim meeting in October, 2005, 162 participants divided the overall problem space into two separate 163 "sub-problems" to solve based on network topology. These two 164 problems are referred to as "Hubs and Spokes" (described in 165 section 3) and "Mesh" (described in Section 4). 167 As stated, there are two scenarios that emerged when discussing the 168 traversal of networks composed of differing address families. The 169 scenarios are quite common in today's network deployments. The 170 primary difference between "Spokes and Hubs" and "Mesh" is how many 171 connections and associated routes are managed by each IPv4 or IPv6 172 "island". "Hubs and Spokes" is characterized with one connection and 173 associated static default route, and "Mesh" is characterized by 174 multiple connections and routing prefixes. In general, the two can 175 be categorized as host or LAN connectivity and network (or VPN) 176 connectivity problems. Looking at the history of multi-address 177 family networking, the clear delineation of the two scenarios was 178 never clearly illustrated but they are now the network norm, and both 179 must be solved. Later during the solution phase of the WG, these 180 problems will be treated as related, but separate, problem spaces. 181 Similar protocols and mechanisms will be used when possible, but 182 different protocols and mechanisms may be selected when necessary to 183 meet the requirements of each given problem space. 185 1.1. Terminology 187 Address Family (AF) - IPv4 or IPv6. Presently defined values for 188 this field are specified in 189 http://www.iana.org/assignments/address-family-numbers. 191 Address Family Border Router (AFBR) - The router that interconnects 192 two networks that use different address families. 194 Customer Premise Equipment (CPE) - Under the scope of this document, 195 this refers to terminal and associated equipment and inside wiring 196 located at a subscriber's premises and connected with a carrier's 197 communication channel(s) at the demarcation point (" demarc "). The 198 demarc is a point established in a building or complex to separate 199 customer equipment from telephone, cable or other service provider 200 equipment. CPE can be a host or router, depending on the specific 201 characteristics of the access network. The demarc point for IPv4 may 202 or may not be the same as the demarc point for IPv6, thus there can 203 be one CPE box acting for IPv4 and IPv6 or two separate ones, one for 204 IPv4 and one for IPv6. 206 Home gateway - Existing piece of equipment that connects the home 207 network to the provider network. Usually act as CPE for one or both 208 address family. 210 Softwire (SW) - A "tunnel" that is created on the basis of a control 211 protocol setup between softwire endpoints with shared point-to-point 212 or multipoint-to-point state. Softwires are generally dynamic in 213 nature (they may be initiated and terminated on demand), but may be 214 very long-lived. 216 Softwire Concentrator (SC) - The node terminating the softwire in the 217 service provider network. 219 Softwire Initiator (SI) - The node initiating the softwire within the 220 customer network. 222 Softwire Transport Header AF (STH AF) - the address family of the 223 outermost IP header of a softwire. 225 Softwire Payload Header AF (SPH AF) - the address family of the IP 226 headers being carried within a softwire. Note that additional 227 "levels" of IP headers may be present if (for example) a tunnel is 228 carried over a softwire - the key attribute of SPH AF is that it is 229 directly encapsulated within the softwire and the softwire endpoint 230 will base forwarding decisions on the SPH AF when a packet is exiting 231 the softwire. 233 Subsequent Address Family (SAF) - Additional information about the 234 type of the additional information about the type of the Network 235 Layer Reachability Information (e.g. unicast or multicast). 237 2. Hubs and Spokes Problem 239 The "Hubs and Spokes" problem is named in reference to the airline 240 industry where major companies have establised a relatively small 241 number of well connected hubs and then serve smaller airports from 242 those hubs. 244 Manually configured tunnels (as described in [RFC4213] ) can be 245 sufficient transition mechanism in some situations. However, cases 246 where NAT traversal is a concern (see section 2.3), or dynamic IP 247 address configuration is required, another solution is necessary. 249 There are four variant cases of the Hubs and Spokes problem which are 250 shown in the following figures. 252 +-------+ +------------+ +--------+ 253 | | |Softwire | | IPv6 | 254 +---------+ | IPv4 |--|concentrator|--| Network|=>Internet 255 |v4/v6 |--| | +------------+ +--------+ 256 |Host CPE | | | 257 +---------+ |Network| 258 +-------+ 259 _ _ _ _ _ _ __ 260 ()_ _ _ _ _ _ __() IPv6 SPH 261 "softwire" 262 |--------------||-------------------------| 263 IPv4-only IPv6 or dual-stack 265 Case 1: IPv6 connectivity across an IPv4-only access network (STH). 266 Softwire initiator is the host CPE (directly connected to a modem), 267 which is dual-stack. There is no other gateway device. The IPv4 268 traffic should not traverse the softwire. 270 Figure 1: Case 1 272 +-------+ +-------------+ +--------+ 273 | | | Softwire | | v6 | 274 +-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet 275 |v4/v6|--|v4/v6 |--| | +-------------+ +--------+ 276 |Host | |Router| |Network| 277 +-----+ |v4/v6 | | | 278 | CPE | +-------+ 279 +------+ 280 _ _ _ _ _ _ __ 281 ()_ _ _ _ _ _ __() IPv6 SPH 282 "softwire" 283 |--------------||--------------||-------------------------| 284 Dual-stack IPv4-only IPv6 or dual-stack 286 Case 2: IPv6 connectivity across an IPv4-only access network (STH). 287 Softwire initiator is the router CPE, which is a dual-stack device. 288 The IPv4 traffic should not traverse the softwire. 290 Figure 2: Case 2 292 +-------+ +-------------+ +--------+ 293 | | | Softwire | | v6 | 294 +------+ +------+ | v4 |--| concentrator|--| Network|=>Internet 295 |v4/v6 |--|v4 |--| | +-------------+ +--------+ 296 |Host | |Router| |Network| 297 |v6 CPE| |v4 CPE| | | 298 +------+ | | +-------+ 299 +------+ 300 _ _ _ _ _ _ _ _ _ _ _ _ 301 ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH 302 "softwire" 303 |-----------------------||-------------------------| 304 IPv4 only IPv6 or dual-stack 306 Case 3: IPv6 connectivity across an IPv4-only access network (STH). 307 The CPE is IPv4-only. Softwire initiator is a host, which act as an 308 IPv6 host CPE. The IPv4 traffic should not traverse the softwire. 310 Figure 3: Case 3 312 +-----+ 313 |v4/v6| +-------+ +------------+ +-------+ 314 |Host | | | |Softwire | | v6 | 315 +-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet 316 | |v4 |--| | +------------+ +-------+ 317 |---------|Router| |Network| 318 | |v4 CPE| +-------+ 319 +---------+ +------+ 320 |Softwire | 321 |Initiator| 322 |v6 Router| 323 | CPE | 324 +---------+ 325 _ _ _ _ _ _ _ _ _ _ _ _ 326 ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH 327 "softwire" 328 |--------||-----------------------||----------------------| 329 Dual IPv4 only IPv6 or dual-stack 330 stack 332 Case 4: IPv6 connectivity across an IPv4-only access network (STH). 333 The routing CPE is IPv4-only. Softwire initiator is a device acting 334 as an IPv6 CPE router inside the home network. The IPv4 traffic 335 should not traverse the softwire. 337 Figure 4: Case 4 339 The converse cases exist, replacing IPv4 by IPv6 and vice versa in 340 the above figures. 342 2.1. Description 344 In this scenario, carriers (or large enterprise networks acting as 345 carriers for their internal networks) have an infrastructure which in 346 at least one device on any given path supports only one address 347 family, with customers who wish to support applications bound to an 348 address family that cannot be routed end-to-end. The address family 349 that must be "crossed" is called the Softwire Transport Header, or 350 STH AF (which could be either IPv4 or IPv6). 352 In order to support applications bound to another address family (the 353 Softwire Payload Header Address Family, or SPH AF), it is necessary 354 to establish a virtual dual-stack infrastructure (end-to-end), 355 typically by means of automatically-established tunnels (Softwires). 356 The traffic that can traverse the network via its native AF must not 357 be forced to take the softwire path. Only the traffic that otherwise 358 would not be able to be forwarded due to the AF mismatch should be 359 forwarded within the softwire. The goal is to avoid overwhelming the 360 softwire concentrator (SC). 362 A network operator may choose to enable a single address family in 363 one or several parts of this infrastructure for policy reasons (i.e., 364 traffic on the network is dominant in one of the address families, a 365 single address family is used to lower OAM cost, etc.) or for 366 technical reasons (i.e., because one or more devices are not able to 367 support both address families). 369 There are several obstacles that may preclude support for both 370 address families: 372 a) One or more devices (routers or some other media-specific 373 aggregation point device) being used across the infrastructure (core, 374 access) that supports only one address family. Typically the reasons 375 for this situation include a lack of vendor support for one of the 376 address families, the (perceived) cost of upgrading them, the 377 (perceived) complexity of running both address families natively, 378 operation/management reasons to avoid upgrades (perhaps temporarily), 379 or economic reasons (such as a commercially insignificant amount of 380 traffic with the non-supported address family). 382 b) The home gateway (CPE router or other equipment at the demarc 383 point), cannot be easily upgraded to support both address families. 384 Typically the reason for this is the lack of vendor support for one 385 of the address families, commercial or operational reasons for not 386 carrying out the upgrade (i.e., operational changes and/or cost may 387 need to be supported by the carrier for all the customers, which can 388 turn into millions of units), or customer reluctance to change/ 389 upgrade CPE router (cost, "not broken, so don't change it"). Note 390 that the un-practicality of systematic upgrades of the CPE routers is 391 also hindering the deployment of 6to4 based solutions [RFC3056] in 392 IPv4 networks. 394 2.2. Non-upgradable CPE router 396 Residential and small-office CPE equipment may be limited to support 397 only one address family. Often, they are owned by a customer or 398 carrier who is unwilling or unable to upgrade them to run in dual 399 stack mode (as shown in Figure 3 and Figure 4). 401 When the CPE router cannot run in dual-stack mode a softwire will 402 have to be established by a node located behind that CPE router. 403 This can be accomplished either by a regular host in the home running 404 softwire software (Figure 1 or Figure 3) or by a dedicated piece of 405 hardware acting as the "IPv6 router" (Figure 4). Such a device is 406 fairly simple in design and only requires one physical network 407 interface. Again, only the traffic of the mismatched AF will be 408 forwarded via the softwire. Traffic that can otherwise be forwarded 409 without a softwire should not be encapsulated. 411 2.3. Network Address Translation (NAT) and Port Address Translation 412 (PAT) 414 A typical case of non-upgradable CPE router is a pre-existing IPv4/ 415 NAT home gateway, so the softwires solution must support NAT 416 traversal. 418 Establishing a Softwire through NAT or PAT must be supported without 419 an explicit requirement to "autodetect" NAT or PAT presence during 420 softwire setup. Simply enabling NAT traversal could be sufficient to 421 meet this requirement. 423 Although the tunneling protocol must be able to traverse NATs, 424 tunneling protocols may have an optional capability to bypass UDP 425 encapsulation if not traversing a NAT. 427 2.4. Static Prefix Delegation 429 An important characteristic of this problem in IPv4 networks is that 430 the carrier-facing CPE IP address is typically dynamically assigned 431 (The IP address of the node establishing the softwire behind the CPE 432 router can also be dynamically assigned.) 434 Solutions like external dynamic DNS and dynamic NAT port forwarding 435 have been deployed to deal with ever changing addresses, but it would 436 be simpler if, in IPv6 networks, a static prefix was delegated to 437 customers. Such a prefix would allow for the registration of stable 438 addresses in the DNS and enable the use of solutions like RFC3041 439 privacy extension or cryptographically generated addresses (CGA) 440 [RFC3972]. 442 The softwire protocol does not need to define a new method for prefix 443 delegation however DHCPv6 prefix delegation must be able to run over 444 a softwire. 446 Link local addresses allocated at both ends of the tunnel are enough 447 for packet forwarding, but for management purpose like traceroute, 448 global addresses can be allocated using existing protocols such as 449 stateless address auto-configuration or DHCPv6. 451 The IP addresses of the softwire link itself do not need to be 452 stable, the desire for stability only applies to the delegated 453 prefix. Even if there is a single node attached behind a softwire 454 link, nothing prevents a softwire concentrator to delegate it a /64 455 prefix. 457 Similarly, in the case of an IPv4 softwire, the address could be 458 provided by means of DHCP. In the case of an IPv4 softwire, a 459 mechanism should be available in order to delegate an IPv4 prefix. 461 Note about 6to4: This is one of the main difference between Softwires 462 and 6to4. 6to4 addresses will change every time the CPE router will 463 get a new external address, where a DHCPv6 delegated prefix through a 464 Softwire link could be stable. 466 2.5. Softwire Initiator 468 In the Hubs and Spokes problem, softwires are always initiated by the 469 customer side. Thus, the node hosting the end of the softwire within 470 the customer network is called the softwire initiator. It can run on 471 any dual-stack node. As noted earlier, this can be the CPE access 472 device, another dedicated CPE router behind the original CPE access 473 device or actually any kind of node (host, appliance, sensor, etc.). 475 The softwire initiator node can change over time and may or may not 476 be delegated the same IP address for the softwire endpoint. In 477 particular, softwires should work in the nomadic case (e.g. a user 478 opening up his laptop in various Wi-Fi hot-spots), where the softwire 479 initiator could potentially obtain an IP address of one address 480 family outside its original carrier network and still want to obtain 481 the other address family addresses from its carrier. 483 If and when the IPv4 provider periodically changes the IPv4 address 484 allocated to the gateway, the softwire initiator has to discover in a 485 reasonable amount of time that the tunnel is down and restart it. 486 This re-establishment should not change the IPv6 prefix and other 487 parameters allocated to the site. 489 2.6. Softwire Concentrator 491 On the carrier side, softwires are terminated on a softwire 492 concentrator. A softwire concentrator is usually a dual-stack router 493 connected to the dual-stack core of the carrier. 495 A carrier may deploy several softwire concentrators (for example one 496 per POP) for scalability reasons. 498 Softwire concentrators are usually not nomadic and have stable IP 499 addresses. 501 It may be the case that one of the address families is not natively 502 supported on the interface facing the core of the carrier. 503 Connectivity must then be provided by other tunnels, potentially 504 using the softwire mesh model. 506 Softwire concentrator functionality will be based on existing 507 standards for tunneling, prefixes and addresses allocation, 508 management. The working group must define a Softwires Concentrator 509 architecture and interaction between these protocols and recommend 510 profiles. These recommendations must take into account the 511 distributed nature of the Softwires Concentrator in the provider 512 network and the impact on core IPv6 networks (for instance: prefix 513 aggregation). 515 2.7. Softwire Concentrator Discovery 517 The softwire initiator must know the DNS name or IP address of the 518 softwire concentrator. An automated discovery phase may be used to 519 return the IP address(s), or name(s) of the concentrator. 520 Alternatively, this information may be configured by the user, or or 521 by the provider of the softwire initiator in advance. The details of 522 this discovery problem are outside the scope of this document, 523 however previous work could be taken in consideration. Examples 524 include: [I-D.durand-naptr-service-discovery], [I-D.ietf-v6ops-ipsec- 525 tunnels], and [I-D.palet-v6ops-tun-auto-disc]. 527 2.8. Scaling 529 In a hubs and spokes model, a carrier must be able to scale the 530 solution to millions of softwire initiators by adding more hubs (i.e. 531 softwire concentrators). 533 2.9. Routing 535 As customer networks are typically attached via a single link to 536 their carrier, the minimum routing requirement is a default route for 537 each of the address families. 539 2.10. Multicast 541 Softwires must support multicast. 543 2.11. Security 545 2.11.1. Authentication, Authorization and Accounting 547 The softwire protocol must support customer authentication in the 548 control plane, in order to authorize access to the service, and 549 provide adequate logging of activity (accounting). However, an 550 carrier may decide to turn it off in some circumstances, for 551 instance, when the customer is already authenticated by some other 552 means, such as closed networks, cellular networks, etc., in order to 553 avoid unnecessary overhead. 555 The protocol should offer mutual authentication in scenarios where 556 the initiator requires identity proof from the concentrator. 558 The softwire solution, at least for "Hubs and Spokes", must be 559 integrable with commonly deployed AAA solutions (although extensions 560 to those AAA solutions may be needed). 562 2.11.2. Privacy, Integrity, and Replay protection 564 The softwire Control and/or Data plane must be able to provide full 565 payload security (such as IPsec or SSL) when desired. This 566 additional protection must be separable from the tunneling aspect of 567 the softwire mechanism itself. For IPsec, default profiles must be 568 defined. [draft-ietf-v6ops-ipsec-tunnels] provides guidelines on 569 this. 571 2.12. Operations and Management (O&M) 573 As it is assumed that the softwire may have to go across NAT or PAT, 574 a keepalive mechanism must be defined. Such a mechanism is also 575 useful for dead peer detection. However in some circumstances (i.e., 576 narrowband access, billing per traffic, etc.) the keepalive mechanism 577 may consume unnecessary bandwidth, so turning it on or off, and 578 modifying the periodicity, must be supported administrative options. 580 Other needed O&M features include: 582 - Logging 584 - Usage accounting 586 - End-point failure detection (the detection mechanism must operate 587 within the tunnel) 589 - Path failure detection (the detection mechanism must operate 590 outside the tunnel) 592 2.13. Encapsulations 594 IPv6/IPv4, IPv6/UDP/IPv4 and IPv4/IPv6 are on the critical path for 595 "Hubs and Spokes" softwires. There is no intention to place limits 596 on additional encapsulations beyond those explicitly mentioned in 597 this specification. 599 3. Mesh Problem 601 3.1. Description 603 We use the term "Mesh Problem" to describe the problem of supporting 604 a general routed topology in which a backbone network that does not 605 support a particular address family can be used as part of the path 606 for packets that belong to that address family. For example, the 607 path for an IPv4 packet might include a transit network which 608 supports only IPv6. There might (or might not) be other paths that 609 the IPv4 packet could take that do not use the IPv6 transit network; 610 the actual path chosen will be determined by the IPv4 routing 611 procedures. 613 By saying that the transit network supports only a single address 614 family, we mean that the "core" routers of that network do not 615 maintain routing information for other address families, and they may 616 not even be able to understand the packet headers of other address 617 families. We do suppose though that the core will have "edge 618 routers" or "border routers" which maintain the routing information 619 for both address families, and which can parse the headers of both 620 address families. We refer to these as "Address Family Border 621 Routers" (AFBRs). 623 The following figure shows an AF2-only network connected to AF1-only 624 networks, AF2-only networks, and dual stack networks. Note that in 625 addition to paths through the AF2-only core, other paths may also 626 exist between AF1 networks. The AFBRs which support AF1 would use 627 BGP to exchange AF1 routing information between themselves, but such 628 information would not be distributed to other core routers. The 629 AFBRs would also participate in the exchange of AF2 routing 630 information with the core nodes. 632 +----------+ +----------+ 633 |AF1 only | |AF1 only | 634 | | | | 635 +----------+ +----------+ 636 | | 637 | | 638 Dual-Stack Dual-Stack 639 "AFBR" "AFBR" 640 | | 641 | | 642 +----------------------------+ 643 | | 644 +-------+ | | +-------+ 645 |AF2 | | AF2 only | |AF2 | 646 |only |-------| (but also providing |-------|only | 647 +-------+ | transit for AF1) | +-------+ 648 | | 649 +----------------------------+ 650 | / \ | 651 | / \ | 652 Dual-Stack Dual-Stack 653 "AFBR" "AFBR" 654 | | | 655 | | | 656 +--------+ +--------+ 657 |AF1 and | |AF1 and | 658 |AF2 | |AF2 | 659 +--------+ +--------+ 661 Figure 5: Mesh Topology 663 The situation in which a pair of border routers use BGP to exchange 664 routing information that is not known to the core routers is 665 sometimes known, somewhat misleadingly, as a "BGP-free core". In 666 this sort of scenario, the problems to be solved are (a) to make sure 667 that the BGP-distributed routing updates for AF1 allow a given AFBR, 668 say AFBR1, to see that the path for a given AF1 address prefix is 669 through a second AFBR, say AFBR2, and (b) to provide a way in which 670 AFBR1 can send AF1 packets through the AF2-only core to AFBR2. Of 671 course, sending AF1 packets through an AF2-only core requires the AF1 672 packets to be encapsulated and sent through "tunnels"; these tunnels 673 are the entities known as "softwires". 675 One of the goals of the mesh problem is to provide a solution which 676 does not require changes in any routers other than the AFBRs. This 677 would allow a carrier (or large enterprise networks acting as carrier 678 for their internal resources) with an AF2-only backbone to provide 679 AF1 transit services for its clients, without requiring any changes 680 whatsoever to the clients' routers, and without requiring any changes 681 to the core routers. The AFBRs are the only devices that perform 682 dual-stack operations, and the only devices that encapsulate and/or 683 decapsulate the AF1 packets in order to send and/or receive them on 684 softwires. 686 It may be recognized that this scenario is very similar to the 687 scenario handled by the L3VPN solution described in RFC 4364. The 688 AFBRs correspond to the "Provider Edge Routers" (PE) of RFC 4364. In 689 those L3VPN scenarios, the PEs exchange routing information in an 690 address family (e.g., the VPN-IPv4 address family), but they send VPN 691 data packets through a core which does not have the VPN routing 692 information. However, the Softwires problem is NOT focused on the 693 situation in which the border routers maintain multiple private 694 and/or overlapping address spaces. Techniques which are specifically 695 needed to support multiple address spaces are in the domain of L3VPN, 696 rather than in the domain of Softwires. 698 Note that the AFBRs may be multiply connected to the core network, 699 and also may be multiply connected to the client networks. Further, 700 the client networks may have "backdoor connections" to each other, 701 through private networks or through the Internet. 703 3.2. Scaling 705 In the mesh problem, the number of AFBRs a backbone network 706 supporting only AF2 will need is approximately on the order of the 707 number of AF1 networks to which it connects. (This is really an 708 upper limit, since a single AFBR can connect to many such networks.) 710 An AFBR may need to exchange a "full Internet's" worth of routing 711 information with each network to which it connects. If these 712 networks are not VPNs, the scaling issues associated with the amount 713 of routing information are just the usual scaling issues faced by the 714 border routers of any network which is providing Internet transit 715 services. (If the AFBRs are also attached to VPNs, the usual L3VPN 716 scaling issues apply, as discussed in RFC 4364 and RFC4365.) The 717 number of BGP peering connections can be controlled through the usual 718 methods, e.g., use of route reflectors. 720 3.3. Persistence, Discovery and Setup Time 722 AFBRs may discover each other, and may obtain any necessary 723 information about each other, as a byproduct of the exchange of 724 routing information (essentially in the same way that PE routers 725 discovery each other in L3VPNs). This may require the addition of 726 new protocol elements or attributes to existing protocols. 728 The softwires needed to allow packets to be sent from one AFBR to 729 another should be "always available", i.e., should not require any 730 extended setup time that would impart an appreciable delay to the 731 data packets. 733 3.4. Multicast 735 If the AF2 core does not provide native multicast services, multicast 736 between AF1 client networks should still be possible, even though it 737 may require replication at the AFBRs and unicasting of the replicated 738 packets through Softwires. If native multicast services are enabled, 739 it should be possible to use these services to optimize the multicast 740 flow. 742 3.5. Softwire Encapsulation 744 The solution to the mesh problem must not require the use of any one 745 encapsulation. Rather, it must accommodate the use of a variety of 746 different encapsulation mechanisms, and a means for choosing the one 747 to be used in any particular circumstance based on policy. 749 In particular, the solution to the mesh problem must allow for at 750 least the following encapsulations to be used: L2TPv3, IP-in-IP, MPLS 751 (LDP-based and RSVP-TE based), GRE, and IPsec. The choice of 752 encapsulation is to be based on policy, and the policies themselves 753 may be based on various characteristics of the packets, of the 754 routes, or of the softwire endpoints themselves. 756 3.6. Security 758 In the mesh problem, the routers are not advertising routes for 759 individual users. So the mesh problem does not require the fine- 760 grained authentication that is required by the hub and spoke problem. 761 There should however be a way to provide various levels of security 762 for the data packets being transmitted on a softwire. The softwire 763 solution must support IPsec and an IPsec profile must be defined. 764 (see recommendations in [I-D.bellovin-useipsec]). 766 Security mechanisms for the control protocols are also required. It 767 must be possible to protect control data from being modified in 768 flight by an attacker, and to prevent an attacker from masquerading 769 as a legitimate control protocol participant. 771 The verification of the reachability information exchanged and issues 772 surrounding the security of routing protocols themselves is outside 773 the scope of the specification. 775 4. Security Considerations 777 Security considerations specific to the "Hubs and Spokes" and "Mesh" 778 models appear in those sections of the document. 780 As with any tunneling protocol, using this protocol may introduce a 781 security issue by circumventing a site security policy implemented as 782 ingress filtering, since these filters will only be applied to STH AF 783 IP headers. 785 5. IANA Considerations 787 There are no IANA actions requested in this specification. 789 6. Changes from -01 791 1. Detailed mailing list comments from Jordi Palet Marinez 792 (2006/03/07). 794 2. Detailed mailing list comments from Pekka Savola (2006/05/03). 796 7. Changes from -00 798 1. Individual-draft authors moved to Authors section, and added an 799 acknowledgements section. 801 2. Detailed mailing list comments from Alain Baudot (2005/12/20). 803 3. Detailed mailing list comments from Pekka Savola (2005/12/22). 805 4. Detailed mailing list comments from Laurent Toutain 806 (2005/12/26). 808 5. Detailed mailing list comments from Francis Dupont (editorial) 809 (2005/12/29). 811 6. Detailed mailing list comments from Francis Dupont (non- 812 editorial) (2005/12/29). 814 7. Detailed mailing list comments from Tom Pusateri (2005/12/29). 816 8. Detailed mailing list comments from Tom Alain Durant 817 (2005/12/30). 819 9. Changed all occurances of "HGW" to "CPE" and added definitio 821 10. Removed all occurances of "TEP" (which seemed to be a synonym 822 for concentrator anyway). 824 11. Changed all occurances of "ISP" to be "operator". 826 12. Removed all RFC 2119 language from the specification (since it's 827 a problem statement). 829 13. Further linguistic clarificatons and edits (2006/01 and 02) 831 14. Remove Compare and Contrast section after discussion w/ authors 832 (2006/02/19) 834 8. Acknowledgements 836 8.1. Authors 838 These are the principal authors for this document. 840 Xing Li 841 CERNET 842 Room 225 Main Building, Tsinghua University 843 Beijing 100084 844 China 846 Phone: +86 10 62785983 847 Fax: +86 10 62785933 848 Email: xing@cernet.edu.cn 850 Figure 6 852 Alain Durand 853 Comcast 854 1500 Market st 855 Philadelphia 856 PA 19102 USA 858 Email: Alain_Durand@cable.comcast.com 860 Figure 7 862 Shin Miyakawa 863 NTT Communications 864 3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku 865 Tokyo 866 Japan 868 Phone: +81-3-6800-3262 869 Fax: +81-3-5365-2990 870 Email: miyakawa@nttv6.jp 872 Figure 8 874 Jordi Palet Martinez 875 Consulintel 876 San Jose Artesano, 1 877 Alcobendas - Madrid 878 E-28108 - Spain 880 Phone: +34 91 151 81 99 881 Fax: +34 91 151 81 98 882 Email: jordi.palet@consulintel.es 884 Figure 9 886 Florent Parent 887 Hexago 888 2875 boul. Laurier, suite 300 889 Sainte-Foy, QC G1V 2M2 890 Canada 892 Phone: +1 418 266 5533 893 Email: Florent.Parent@hexago.com 895 Figure 10 897 David Ward 898 Cisco Systems 899 170 W. Tasman Dr. 900 San Jose, CA 95134 901 USA 903 Phone: +1-408-526-4000 904 Email: dward@cisco.com 906 Figure 11 908 Eric C. Rosen 909 Cisco Systems 910 1414 Massachusetts Avenue 911 Boxborough, MA, 01716 912 USA 914 Email: erosen@cisco.com 916 Figure 12 918 8.2. Contributors 920 The authors would like to acknowledge the following contributors who 921 provided helpful inputs on earlier versions of this document: Alain 922 Baudot, Hui Deng, Francis Dupont, Rob Evans, Ed Koehler Jr, Erik 923 Nordmark, Soohong Daniel Park, Tom Pusateri, Pekka Savola, Bruno 924 Stevant, Laurent Totain, Bill Storer, Maria (Alice) Dos Santos, Yong 925 Cui, Chris Metz, Simon Barber, Skip Booth, Scott Wainner and Carl 926 Williams. 928 The authors would also like to acknowledge the participants in the 929 Softwires interim meeting in Paris, France (October 11-12, 2005) 930 (minutes are at 931 http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm). 933 The authors would also like to express a special acknowledgement and 934 thanks to Mark Townsley. Without his leadership, persistence, 935 editing skills and thorough suggestions for the document; we would 936 have not have been successful. 938 Tunnel-based transition mechanisms have been under discussion in the 939 IETF for more than a decade. Initial work related to softwire can be 940 found in RFC3053. The earlier "V6 Tunnel Configuration" BOF problem 941 statement [I-D.palet-v6tc-goals-tunneling] includes a reasonable 942 pointer to prior work. 944 9. References 946 9.1. Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 952 Translator (NAT) Terminology and Considerations", 953 RFC 2663, August 1999. 955 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 956 Stateless Address Autoconfiguration in IPv6", RFC 3041, 957 January 2001. 959 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 960 Tunnel Broker", RFC 3053, January 2001. 962 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 963 via IPv4 Clouds", RFC 3056, February 2001. 965 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 966 RFC 3972, March 2005. 968 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 969 for IPv6 Hosts and Routers", RFC 4213, October 2005. 971 9.2. Informative References 973 [I-D.bellovin-useipsec] 974 S, "Guidelines for Mandating the Use of IPsec, 975 draft-bellovin-useipsec-04", September 2005. 977 [I-D.durand-naptr-service-discovery] 978 A, ""Service Discovery using NAPTR records in DNS", 979 draft-durand-naptr-service-discovery-00", October 2004. 981 [I-D.ietf-v6ops-ipsec-tunnels] 982 P, ""Using IPsec to Secure IPv6-in-IPv4 Tunnels", 983 draft-ietf-v6ops-ipsec-tunnels-01", August 2005. 985 [I-D.palet-v6ops-solution-tun-auto-disc] 986 J, ""IPv6 Tunnel End-point Automatic Discovery Mechanism", 987 draft-palet-v6ops-solution-tun-auto-disc-01", 988 October 2004. 990 [I-D.palet-v6ops-tun-auto-disc] 991 J and M, ""Analysis of IPv6 Tunnel End-point Discovery 992 Mechanisms", draft-palet-v6ops-tun-auto-disc-03", 993 January 2005. 995 [I-D.palet-v6tc-goals-tunneling] 996 J, ""Goals for Tunneling Configuration", 997 draft-palet-v6tc-goals-tunneling-00", February 2005. 999 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1000 Networks (VPNs)", RFC 4364, February 2006. 1002 [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP 1003 Virtual Private Networks (VPNs)", RFC 4365, February 2006. 1005 Author's Address 1007 Spencer Dawkins (editor) 1008 Huawei Technologies (USA) 1009 1700 Alma Drive, Suite 100 1010 Plano, TX 75075 1011 US 1013 Phone: +1 972 509 0309 1014 Fax: +1 469 229 5397 1015 Email: spencer@mcsr-labs.org 1017 Full Copyright Statement 1019 Copyright (C) The IETF Trust (2007). 1021 This document is subject to the rights, licenses and restrictions 1022 contained in BCP 78, and except as set forth therein, the authors 1023 retain all their rights. 1025 This document and the information contained herein are provided on an 1026 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1027 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1028 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1029 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1030 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1031 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1033 Intellectual Property 1035 The IETF takes no position regarding the validity or scope of any 1036 Intellectual Property Rights or other rights that might be claimed to 1037 pertain to the implementation or use of the technology described in 1038 this document or the extent to which any license under such rights 1039 might or might not be available; nor does it represent that it has 1040 made any independent effort to identify any such rights. Information 1041 on the procedures with respect to rights in RFC documents can be 1042 found in BCP 78 and BCP 79. 1044 Copies of IPR disclosures made to the IETF Secretariat and any 1045 assurances of licenses to be made available, or the result of an 1046 attempt made to obtain a general license or permission for the use of 1047 such proprietary rights by implementers or users of this 1048 specification can be obtained from the IETF on-line IPR repository at 1049 http://www.ietf.org/ipr. 1051 The IETF invites any interested party to bring to its attention any 1052 copyrights, patents or patent applications, or other proprietary 1053 rights that may cover technology that may be required to implement 1054 this standard. Please address the information to the IETF at 1055 ietf-ipr@ietf.org. 1057 Acknowledgment 1059 Funding for the RFC Editor function is provided by the IETF 1060 Administrative Support Activity (IASA).