idnits 2.17.1 draft-ietf-softwire-problem-statement-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1023. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 22, 2006) is 6541 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) == Unused Reference: 'RFC2119' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipsec-tunnels' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'I-D.palet-v6ops-solution-tun-auto-disc' is defined on line 975, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3053 == 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: 6 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 Expires: November 23, 2006 May 22, 2006 6 Softwire Problem Statement 7 draft-ietf-softwire-problem-statement-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Softwires Working Group is specifying the standardization of 41 discovery, control and encapsulation methods for connecting IPv4 42 networks across IPv6-only networks and IPv6 networks across IPv4-only 43 networks in a way that will encourage multiple, inter-operable vendor 44 implementations. At the highest level, the Softwires Working Group 45 is tasked to identify, and extend where necessary, standard protocols 46 to support a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition 47 problems. This document describes the specific problems ("Hubs and 48 Spokes" and "Mesh") that will be solved as part of a solution phase 49 following the completion of this document, within a relatively tight 50 "time-to-market" as requested by operators at IETF 63. Some 51 individual requirements (and non-requirements) are also identified in 52 this document at times in order to better describe the specific scope 53 for a given problem definition. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 7 60 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 61 2.2. Non-upgradable CPE router . . . . . . . . . . . . . . . . 10 62 2.3. Network Address Translation (NAT) and Port Address 63 Translation (PAT) . . . . . . . . . . . . . . . . . . . . 11 64 2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 11 65 2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 12 66 2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 12 67 2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12 68 2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 2.11.1. Authentication, Authorization and Accounting . . . . 13 73 2.11.2. Privacy, Integrity, and Replay protection . . . . . . 14 74 2.12. Operations and Management (O&M) . . . . . . . . . . . . . 14 75 2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 14 76 3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.1. Mesh Description . . . . . . . . . . . . . . . . . . . . . 16 78 3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.3. Persistence, Discovery and Setup Time . . . . . . . . . . 17 80 3.4. Address Family/SAF Reachability . . . . . . . . . . . . . 17 81 3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 17 82 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 3.7. Operations and Management . . . . . . . . . . . . . . . . 18 84 3.8. Address Family Encapsulations . . . . . . . . . . . . . . 19 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 6. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . . 22 88 7. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 23 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 90 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 8.2. Contributors . . . . . . . . . . . . . . . . . . . . . . . 25 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 Intellectual Property and Copyright Statements . . . . . . . . . . 30 98 1. Introduction 100 The Softwires Working Group is specifying the standardization of 101 discovery, control and encapsulation methods for connecting IPv4 102 networks across IPv6-only networks and IPv6 networks across IPv4-only 103 networks in a way that will encourage multiple, inter-operable vendor 104 implementations. This document is describing the scenarios that the 105 Working Group is going to focus on leading toward defining solutions. 106 A few generic assumptions are listed up front: 108 o Local Area Networks will often support both protocol families in 109 order to accommodate both IPv4-only and IPv6-only applications, in 110 addition to dual-stack applications. Global reachability requires 111 the establishment of softwire connectivity to transit across 112 portions of the network that do not support both address families. 113 Wide area networks that support one or both address families may 114 be separated by transit networks that do not support all address 115 families. Softwire connectivity is necessary to establish global 116 reachability of both address families. 118 o Softwires are to be used in IP-based networks to forward both 119 unicast and multicast traffic. 121 o Softwires are assumed to be non-ephemeral in nature. 123 o Although Softwires are long-lived, the setup time of a softwire is 124 expected to be a very small fraction of the total time required 125 for startup of the Customer Premise Equipment (CPE)/Address Family 126 Border Router (AFBR). 128 o The nodes that actually initiate softwires should support dual- 129 stack (IPv4 and IPv6) functionality. 131 o The goal of this effort is to reuse or extending existing 132 technology. The 'time-to-market' requirement for solutions to the 133 stated problems is very strict and existing, deployed technology 134 must be very strongly considered in our solution selection. 136 The history of IPv4 and IPv6 transition strategies at the IETF is a 137 very long and complex. Here we list out some steps we have taken to 138 further the effort and it has lead to the creation of this document 139 and a few 'working rules' for us to accomplish our work: 141 o At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF 142 meeting, attendees from several operators requested a very tight 143 timeframe for delivery of a solution, based on time-to-market 144 considerations. This problem statement is narrowly scoped to 145 accommodate near-term deployment. 147 o At the Paris Softwires interim meeting in October, 2005, 148 participants divided the overall problem space into two separate 149 "sub-problems" to solve based on network topology. These two 150 problems are referred to as "Hubs and Spokes" (described in 151 section 3) and "Mesh" (described in Section 4). 153 As stated, there are two scenarios that emerged when discussing the 154 traversal of networks composed of differing address families. The 155 scenarios are quite common in today's network deployments. The 156 primary difference between "Spokes and Hubs" and "Mesh" is how many 157 connections and associated routes are managed by each IPv4 or IPv6 158 "island". "Hubs and Spokes" is characterized with one connection and 159 associated static default route, and "Mesh" is characterized by 160 multiple connections and routing prefixes. In general, the two can 161 be categorized as host or LAN connectivity and network (or VPN) 162 connectivity problems. Looking at the history of multi-address 163 family networking, the clear delineation of the two scenarios was 164 never clearly illustrated but they are now the network norm, and both 165 must be solved. Later during the solution phase of the WG, these 166 problems will be treated as related, but separate, problem spaces. 167 Similar protocols and mechanisms will be used when possible, but 168 different protocols and mechanisms may be selected when necessary to 169 meet the requirements of each given problem space. 171 1.1. Terminology 173 Address Family (AF) - IPv4 or IPv6. Presently defined values for 174 this field are specified in 175 http://www.iana.org/assignments/address-family-numbers. 177 Address Family Border Router (AFBR) - The router that interconnects 178 two networks that use different address families. 180 Customer Premise Equipment (CPE) - Under the scope of this document, 181 this refers to terminal and associated equipment and inside wiring 182 located at a subscriber's premises and connected with a carrier's 183 communication channel(s) at the demarcation point (" demarc "). The 184 demarc is a point established in a building or complex to separate 185 customer equipment from telephone, cable or other service provider 186 equipment. CPE can be a host or router, depending on the specific 187 characteristics of the access network. The demarc point for IPv4 may 188 or may not be the same as the demarc point for IPv6, thus there can 189 be one CPE box acting for IPv4 and IPv6 or two separate ones, one for 190 IPv4 and one for IPv6. 192 Home gateway - Existing piece of equipment that connects the home 193 network to the provider network. Usually act as CPE for one or both 194 address family. 196 Softwire (SW) - A "tunnel" that is created on the basis of a control 197 protocol setup between softwire endpoints with shared point-to-point 198 or multipoint-to-point state. Softwires are generally dynamic in 199 nature (they may be initiated and terminated on demand), but may be 200 very long-lived. 202 Softwire Concentrator (SC) - The node terminating the softwire in the 203 service provider network. 205 Softwire Initiator (SI) - The node initiating the softwire within the 206 customer network. 208 Softwire Transport Header AF (STH AF) - the address family of the 209 outermost IP header of a softwire. 211 Softwire Payload Header AF (SPH AF) - the address family of the IP 212 headers being carried within a softwire. Note that additional 213 "levels" of IP headers may be present if (for example) a tunnel is 214 carried over a softwire - the key attribute of SPH AF is that it is 215 directly encapsulated within the softwire and the softwire endpoint 216 will base forwarding decisions on the SPH AF when a packet is exiting 217 the softwire. 219 Subsequent Address Family (SAF) - Additional information about the 220 type of the additional information about the type of the Network 221 Layer Reachability Information (e.g. unicast or multicast). 223 2. Hubs and Spokes Problem 225 The "Hubs and Spokes" problem is named in reference to the airline 226 industry where major companies have establised a relatively small 227 number of well connected hubs and then serve smaller airports from 228 those hubs. 230 In some applications, manually configured tunnels (as described in 231 [RFC4213] are sufficient as a transition mechanism. For a variety of 232 reasons (for example, use of dynamic IP addresses, and NAT 233 traversal), other solutions are also necessary. 235 There are four variant cases of the Hubs and Spokes problem which are 236 shown in the following figures. 238 +-------+ +------------+ +--------+ 239 | | |Softwire | | IPv6 | 240 +---------+ | IPv4 |--|concentrator|--| Network|=>Internet 241 |v4/v6 |--| | +------------+ +--------+ 242 |Host CPE | | | 243 +---------+ |Network| 244 +-------+ 245 _ _ _ _ _ _ __ 246 ()_ _ _ _ _ _ __() IPv6 SPH 247 "softwire" 248 |--------------||-------------------------| 249 IPv4-only IPv6 or dual-stack 251 Case 1: IPv6 connectivity across an IPv4-only access network (STH). 252 Softwire initiator is the host CPE (directly connected to a modem), 253 which is dual-stack. There is no other gateway device. The IPv4 254 traffic should not traverse the softwire. 256 Figure 1: Case 1 257 +-------+ +-------------+ +--------+ 258 | | | Softwire | | v6 | 259 +-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet 260 |v4/v6|--|v4/v6 |--| | +-------------+ +--------+ 261 |Host | |Router| |Network| 262 +-----+ |v4/v6 | | | 263 | CPE | +-------+ 264 +------+ 265 _ _ _ _ _ _ __ 266 ()_ _ _ _ _ _ __() IPv6 SPH 267 "softwire" 268 |--------------||--------------||-------------------------| 269 Dual-stack IPv4-only IPv6 or dual-stack 271 Case 2: IPv6 connectivity across an IPv4-only access network (STH). 272 Softwire initiator is the router CPE, which is a dual-stack device. 273 The IPv4 traffic should not traverse the softwire. 275 Figure 2: Case 2 277 +-------+ +-------------+ +--------+ 278 | | | Softwire | | v6 | 279 +------+ +------+ | v4 |--| concentrator|--| Network|=>Internet 280 |v4/v6 |--|v4 |--| | +-------------+ +--------+ 281 |Host | |Router| |Network| 282 |v6 CPE| |v4 CPE| | | 283 +------+ | | +-------+ 284 +------+ 285 _ _ _ _ _ _ _ _ _ _ _ _ 286 ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH 287 "softwire" 288 |-----------------------||-------------------------| 289 IPv4 only IPv6 or dual-stack 291 Case 3: IPv6 connectivity across an IPv4-only access network (STH). 292 The CPE is IPv4-only. Softwire initiator is a host, which act as an 293 IPv6 host CPE. The IPv4 traffic should not traverse the softwire. 295 Figure 3: Case 3 296 +-----+ 297 |v4/v6| +-------+ +------------+ +-------+ 298 |Host | | | |Softwire | | v6 | 299 +-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet 300 | |v4 |--| | +------------+ +-------+ 301 |---------|Router| |Network| 302 | |v4 CPE| +-------+ 303 +---------+ +------+ 304 |Softwire | 305 |Initiator| 306 |v6 Router| 307 | CPE | 308 +---------+ 309 _ _ _ _ _ _ _ _ _ _ _ _ 310 ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH 311 "softwire" 312 |--------||-----------------------||----------------------| 313 Dual IPv4 only IPv6 or dual-stack 314 stack 316 Case 4: IPv6 connectivity across an IPv4-only access network (STH). 317 The routing CPE is IPv4-only. Softwire initiator is a device acting 318 as an IPv6 CPE router inside the home network. The IPv4 traffic 319 should not traverse the softwire. 321 Figure 4: Case 4 323 The converse cases exist, replacing IPv4 by IPv6 and vice versa in 324 the above figures. 326 2.1. Description 328 In this scenario, carriers (or large enterprise networks acting as 329 carriers for their internal networks) have an infrastructure which in 330 at least one device on any given path supports only one address 331 family, with customers who wish to support applications bound to an 332 address family that cannot be routed end-to-end. The address family 333 that must be "crossed" is called the Softwire Transport Header, or 334 STH AF (which could be either IPv4 or IPv6). 336 In order to support applications bound to another address family (the 337 Softwire Payload Header Address Family, or SPH AF), it is necessary 338 to establish a virtual dual-stack infrastructure (end-to-end), 339 typically by means of automatically-established tunnels (Softwires). 340 The traffic that can traverse the network via its native AF must not 341 be forced to take the softwire path. Only the traffic that otherwise 342 would not be able to be forwarded due to the AF mismatch should be 343 forwarded within the softwire. The goal is to avoid overwhelming the 344 softwire concentrator (SC). 346 A network operator may choose to enable a single address family in 347 one or several parts of this infrastructure for policy reasons (i.e., 348 traffic on the network is dominant in one of the address families, a 349 single address family is used to lower OAM cost, etc.) or for 350 technical reasons (i.e., because one or more devices are not able to 351 support both address families). 353 There are several obstacles that may preclude support for both 354 address families: 356 a) One or more devices (routers or some other media-specific 357 aggregation point device) being used across the infrastructure (core, 358 access) that supports only one address family. Typically the reasons 359 for this situation include a lack of vendor support for one of the 360 address families, the (perceived) cost of upgrading them, the 361 (perceived) complexity of running both address families natively, 362 operation/management reasons to avoid upgrades (perhaps temporarily), 363 or economic reasons (such as a commercially insignificant amount of 364 traffic with the non-supported address family). 366 b) The home gateway (CPE router or other equipment at the demarc 367 point), cannot be easily upgraded to support both address families. 368 Typically the reason for this is the lack of vendor support for one 369 of the address families, commercial or operational reasons for not 370 carrying out the upgrade (i.e., operational changes and/or cost may 371 need to be supported by the carrier for all the customers, which can 372 turn into millions of units), or customer reluctance to change/ 373 upgrade CPE router (cost, "not broken, so don't change it"). 375 2.2. Non-upgradable CPE router 377 Residential and small-office CPE equipment may be limited to support 378 only one address family. Often, they are owned by a customer or 379 carrier who is unwilling or unable to upgrade them to run in dual 380 stack mode (as shown in Figure 3 and Figure 4). 382 When the CPE router cannot run in dual-stack mode a softwire will 383 have to be established by a node located behind that CPE router. 384 This can be accomplished either by a regular host in the home running 385 softwire software (Figure 1 or Figure 3) or by a dedicated piece of 386 hardware acting as the "IPv6 router" (Figure 4). Such a device is 387 fairly simple in design and only requires one physical network 388 interface. Again, only the traffic of the mismatched AF will be 389 forwarded via the softwire. Traffic that can otherwise be forwarded 390 without a softwire should not be encapsulated. 392 2.3. Network Address Translation (NAT) and Port Address Translation 393 (PAT) 395 A typical case of non-upgradable CPE router is a pre-existing IPv4/ 396 NAT home gateway, so the softwires solution must support NAT 397 traversal. 399 If the NAT is not in the home gateway, but in carrier equipment 400 located at the other end of the access link (typically in an carrier 401 POP), support for NAT traversal is still required. 403 Establishing a Softwire through NAT or PAT must be supported without 404 an explicit requirement to "autodetect" NAT or PAT presence during 405 softwire setup. Simply enabling NAT traversal could be sufficient to 406 meet this requirement. 408 Although the tunneling protocol must be able to traverse NATs, 409 tunneling protocols may have an optional capability to bypass UDP 410 encapsulation if not traversing a NAT. 412 2.4. Static Prefix Delegation 414 An important characteristic of this problem in IPv4 networks is that 415 the carrier-facing CPE IP address is typically dynamically assigned. 416 Also, if the softwire has to be established from a node behind a CPE 417 router, that node IP address can also be dynamically assigned. In 418 cases where static IP addresses are unavailable, dynamic addresses 419 are a problem for some Internet accessible services. Solutions like 420 external dynamic DNS and dynamic NAT port forwarding have been 421 deployed, but it would be simpler if, in IPv6 networks, a static 422 prefix was delegated to the customer, even in the case of single node 423 network. That prefix would allow for the registration of stable 424 addresses in the DNS and also enough room to use either RFC3041 425 privacy extension or cryptographically generated addresses (CGA) 426 [RFC3972]. The softwire protocol does not need to define a new 427 method for prefix delegation however DHCPv6 prefix delegation must be 428 able to run over a softwire. Note also that the IP addresses of the 429 softwire link itself do not need to be stable, as, even if a single 430 PC is attached behind it, a /64 prefix will be delegated. 432 Link local addresses allocated at both ends of the tunnel are enough 433 for packet forwarding, but for management purpose like traceroute, 434 global addresses can be allocated using existing protocols such as 435 Neighbor Discovery or DHCPv6. 437 Similarly, in the case of an IPv4 softwire, the address could be 438 provided by means of DHCP. In the case of an IPv4 softwire, a 439 mechanism should be available in order to delegate an IPv4 prefix. 441 2.5. Softwire Initiator 443 In the Hubs and Spokes problem, softwires are always initiated by the 444 customer side. Thus, the node hosting the end of the softwire within 445 the customer network is called the softwire initiator. It can run on 446 any dual-stack node. As noted earlier, this can be the CPE access 447 device, another dedicated CPE router behind the original CPE access 448 device or simply any kind of node (host, appliance, sensor, etc.). 450 The softwire initiator does not have to be always the same node 451 and/or always have been delegated the same IP address. In 452 particular, softwires should work in the nomadic case (e.g. a user 453 opening up his laptop in various Wi-Fi hot-spots), since the softwire 454 initiator could potentially obtain an IP address of one address 455 family outside its original carrier network and still want to obtain 456 the other address family addresses from its original carrier. 458 IPv4 provider can also periodically change the IPv4 address allocated 459 to the gateway. The softwire initiator has to discover in a 460 reasonable period of time that the tunnel is down and restart tunnel 461 establishment. This re-establishment should not change the IPv6 462 prefix and other parameters allocated to the site. 464 2.6. Softwire Concentrator 466 On the carrier side, softwires are terminated on a softwire 467 concentrator. An carrier may deploy several softwire concentrators 468 (for example one per POP) for scalability reasons. A softwire 469 concentrator is in practice a dual-stack router connected to the 470 dual-stack core of the carrier or directly to the upstream providers. 471 Softwire concentrators are not nomadic and have stable IP addresses. 472 It may be the case that one of the address families is not natively 473 supported, even if this is not optimal, in the softwire concentrator, 474 but instead by means of tunnels to the upstreams (or other networks). 476 Softwire concentrator functionality will be based on existing 477 standards for tunneling, prefixes and addresses allocation, 478 management. The working group must define a Softwires Concentrator 479 architecture and interaction between these protocols and recommend 480 profiles. These recommendations must take into account the 481 distributed nature of the Softwires Concentrator in the provider 482 network and the impact on core IPv6 networks (for instance: prefix 483 aggregation). 485 2.7. Softwire Concentrator Discovery 487 The softwire initiator must know the DNS name or IP address of the 488 softwire concentrator. An automated discovery phase may be used to 489 return the IP address(s), or name(s) of the concentrator. 490 Alternatively, this information may be configured by the user, or or 491 by the provider of the softwire initiator in advance. The details of 492 this discovery problem are outside the scope of this document, 493 however previous work could be taken in consideration. Examples 494 include: [I-D.durand-naptr-service-discovery], [I-D.ietf-v6ops-ipsec- 495 tunnels], and [I-D.palet-v6ops-tun-auto-disc]. 497 2.8. Scaling 499 In a hubs and spokes model, a carrier must be able to scale the 500 solution to millions of softwire initiators by adding more hubs (i.e. 501 softwire concentrators). DNS redirection and/or local anycast 502 addresses among other choices, coupled with the (to-be-determined) 503 softwire concentrator discovery solution will enable sharing the load 504 among concentrators. 506 2.9. Routing 508 As customer networks are typically attached via a single link to 509 their carrier, the minimum routing requirement is a default route for 510 each of the address families. 512 2.10. Multicast 514 Existing multicast solutions can be used over the softwire. 515 Typically, such solution would be either Multicast Listener 516 Discovery/Internet Group Membership Protocol proxy [I-D.ietf-magma- 517 igmp-proxy] or Protocol-Independent Multicast. 519 2.11. Security 521 2.11.1. Authentication, Authorization and Accounting 523 The softwire protocol must support customer authentication in the 524 control plane, in order to authorize access to the service, and 525 provide adequate logging of activity (accounting). However, an 526 carrier may decide to turn it off in some circumstances, for 527 instance, when the customer is already authenticated by some other 528 means, such as closed networks, cellular networks, etc., in order to 529 avoid unnecessary overhead. 531 The protocol should offer mutual authentication in scenarios where 532 the initiator requires identity proof from the concentrator. 534 The softwire solution, at least for "Hubs and Spokes", must be 535 integrable with commonly deployed AAA solutions (although extensions 536 to those AAA solutions may be needed). 538 2.11.2. Privacy, Integrity, and Replay protection 540 The softwire Control and/or Data plane must be able to provide full 541 payload security (such as IPsec or SSL) when desired. This 542 additional protection must be separable from the tunneling aspect of 543 the softwire mechanism itself. For IPsec, default profiles must be 544 defined. [draft-ietf-v6ops-ipsec-tunnels] provides guidelines on 545 this. 547 2.12. Operations and Management (O&M) 549 As it is assumed that the softwire may have to go across NAT or PAT, 550 a keepalive mechanism must be defined. Such a mechanism is also 551 useful for dead peer detection. However in some circumstances (i.e., 552 narrowband access, billing per traffic, etc.) the keepalive mechanism 553 may consume unnecessary bandwidth, so turning it on or off, and 554 modifying the periodicity, must be supported administrative options. 556 Other needed O&M features include: 558 - Logging 560 - Usage accounting 562 - End-point failure detection (the detection mechanism must operate 563 within the tunnel) 565 - Path failure detection (the detection mechanism must operate 566 outside the tunnel) 568 2.13. Encapsulations 570 IPv6/IPv4, IPv6/UDP/IPv4 and IPv4/IPv6 are on the critical path for 571 "Hubs and Spokes" softwires. Other encapsulations, like IPv6/IPv6 or 572 IPv4/IPv4, are nice to have but not on the critical path. There is 573 no intention to place limits on additional encapsulations beyond 574 those explicitly mentioned in this specification. 576 3. Mesh Problem 578 The "Mesh" problem is named in reference to typical routing problems 579 in which there are more than one paths to a destination and a routing 580 protocol is needed to select the best path. It is also extremely 581 similar to the problems that the L3VPN Working Group is tackling in 582 which reduced, private and/or overlapping virtual routing and 583 forwarding tables are announced. The key difference is that the 584 reachability that must be announced across the transit core will 585 include more than VPN address family routes. 587 +----------+ +----------+ 588 |differing | |differing | 589 |AF as core| |AF as core| 590 |access | |access | 591 |island | |island | 592 +----------+ +----------+ 593 | | 594 | | 595 Dual-Stack Dual-Stack 596 "AFBR" "AFBR" 597 | | 598 | | 599 +----------------------------+ 600 | | 601 | | 602 +-------+ | | +-------+ 603 |same AF| | Single AF only | |same AF| 604 |as core|-------| transit core |-------|as core| 605 |access | | | |access | 606 |network| | | |network| 607 +-------+ | | +-------+ 608 | | 609 +----------------------------+ 610 | / \ | 611 | / \ | 612 Dual-Stack Dual-Stack 613 "AFBR" "AFBR" 614 | | | 615 | | | 616 +--------+ +--------+ 617 |dual | |dual | 618 |stack | |stack | 619 |access | |access | 620 |island | |island | 621 +--------+ +--------+ 623 Figure 5: Mesh Topology 625 3.1. Mesh Description 627 In this problem, carriers (or large enterprise networks acting as 628 carrier for their internal resources) may be required to establish 629 connectivity to 'islands' of networks of one address family type 630 across a transit core of a differing address family type. For an 631 example, see Figure 5. To provide reachability across the transit 632 core, dual-stack devices are installed that act as "Address Family 633 Border Routers." These AFBRs can be performing peering across 634 autonomous systems or, performing as Provider Edge routers (PE) in 635 VPN parlance within an autonomous system. With respect to deployment 636 considerations, the islands do not have to be upgraded at the time of 637 deploying the transit core and interwork as if there was no awareness 638 of the AFBR. 640 The AFBRs are the only devices in the carrier's network that must be 641 able to perform dual-stack operations and setup and encapsulate 642 softwires in a mesh to the other islands. They then pass 643 reachability information as appropriate according to policy. They 644 may be multiply connected to the transit network and thus, have to be 645 able to exchange appropriate information and make a routing selection 646 choice as to the best exit point. Note that this creates multipoint- 647 to-point reachability using a point-to-point logical overlay of 648 softwire connectivity. 650 It should also be noted that the mesh problem can be considered as a 651 derivative of L3VPN, where the core provides transit in one address 652 family and the islands are connected via L3VPN of another address 653 family. This analogy only holds true if the islands can to be 654 represented as VPNs. In general, the diagrams frequently used for 655 L3VPNs is very similar. The key point is that the reachability 656 information that is to be exchanged must not be limited to VPNs or 657 any single AF or SAF or combination of AF/SAF. The solution must be 658 generic enough to carry any AF or SAF. 660 In the future a tunnel concentrator may be a different device than 661 the AFBR that is announcing reachability. In that future phase, the 662 AFBR may need to announce a third party tunnel concentrator. 664 3.2. Scaling 666 In the mesh problem, the number of AFBRs is on the order of the 667 number of islands though it should be clear that a single AFBR could 668 handle many islands if the islands have distinct routing and 669 forwarding tables. A primary issue in the Mesh problem is that the 670 size of the routing tables exchanged between the islands is of the 671 order of the 'full Internet' (with respect to the island's native 672 Address Family) plus any VPNs. These tables plus the routing tables 673 associated with the transit core (and VPNs of the same AF as the 674 transit core) must be stored on the AFBRs. The number of peering 675 points of an AFBR will be on the order of the number of Autonomous 676 System Border Routers (ASBRs), which are assumed to be multiply 677 peered to the transit core (multi-homed) for reliability. An island 678 can also have multiple AFBRs for reliability as well. Both the 679 island or the transit core may contain route reflectors or 680 hierarchical routing with impunity. 682 An AFBR should be able to pass route filters of data or routing 683 tables it does not wish to receive. Peering AFBRs must adhere to the 684 route or route table filters and not send reachability information. 685 Other attributes that can be sent from one AFBR to the other may 686 include "no export" or similar mechanisms to prevent subsequent 687 reannouncements of reachability information. The scaling of the 688 information to be exchanged is on the order of similar data exchanged 689 for L3VPNs. 691 3.3. Persistence, Discovery and Setup Time 693 Discovery of the AFBRs and softwire encapsulation could be 694 accomplished by the routing protocol during capability advertisement. 695 An alternative is that the endpoints could be passed in new data 696 formats or attributes, within a routing protocol. 698 The duration of the softwire for inter-island reachability is 699 considered to be as long as the duration of the peering session. 700 Thus, dynamicity is very low. The setup time should be on the order 701 of the same duration to setup L3VPNs. 703 3.4. Address Family/SAF Reachability 705 It has been reported that the softwires to connect the islands will 706 need to be able to perform IPv4/IPv6, IPv6/IPv4 and be able to 707 exchange multicast and VPN routing tables. The islands will need to 708 be able to perform multicast routing and if the transit core does not 709 provide native multicast services, the "classic" multicast solutions 710 can be used over the softwires. If native multicast services are 711 enabled, further work may need to be accomplished to optimize the 712 multicast forwarding path, receiver transmission load or receiver 713 load. 715 3.5. Softwire Encapsulation 717 In the strictest sense, the softwire encapsulation has to be dual 718 stack. There is no requirement that only one encapsulation technique 719 must be used. It could be possible to have more than one available 720 at each AFBR. The AFBR must be able to prioritize which 721 encapsulation technique it will use if there is more than one 722 available. 724 The encapsulations used to traverse the transit core must be enabled 725 to handle a choice of methods. Common choices that should create a 726 minimal set would include: L2TPv3, IP in IP, MPLS, IPsec, GRE. The 727 choice of encapsulation must not be subject to either an island or 728 peer-wise limitation. Different AF/SAF combinations must be able to 729 be encapsulated differently according to the requirements of the 730 network deployment. For example, IPv4 unicast may be encapsulated in 731 MPLS while IPv4 VPNs may be encapsulated in IPsec or L2TPv3. This 732 flexibility should not cause multiple peering sessions although it is 733 not precluded that this may be the desired network deployment. There 734 must be a scheme in which preferencing the encapsulation to be used 735 is exchanged between peers. Also, once the softwire encapsulation is 736 established a minimal amount of information must be passed with 737 reachability information to connect the AF/SAF reachability to 738 softwire. The linking of reachability information should not be 739 passed on a per route basis. 741 3.6. Security 743 In contrast with the hubs and spokes problem, routers are advertising 744 route for relatively large network islands, not individual users, so 745 fine-grained authentication is not necessary. However the solution 746 should support security of the softwire mechanism itself or the 747 softwire data plane or both. 749 In the softwire initialization mechanism, the softwire solution must 750 support authentication, but an carrier may decide to turn it off in 751 some circumstances. This means that if a routing protocol is used to 752 advertise the softwire encapsulation, it must also support 753 authentication. 755 In the data plane, the softwire solution must support IPsec and an 756 IPsec profile must be defined. (see recommendations in [I-D.bellovin- 757 useipsec]). 759 The verification of the reachability information exchanged and issues 760 surrounding the security of routing protocols themselves is outside 761 the scope of the specification. 763 3.7. Operations and Management 765 There have been no reports of NATs between the AFBRs (in the transit 766 core) so a NAT detection solution is not needed. 768 Other O&M needed features include: 770 - Usage accounting 772 - End-point failure detection (must be encapsulated within the tunnel 773 in the transmitting direction) 775 - Path failure detection 777 Upon failure of a softwire, all reachability information must be 778 withdrawn or a backup path used immediately. 780 3.8. Address Family Encapsulations 782 IPv6/IPv4, IPv4/IPv6 and overlapping address space as defined in the 783 L3VPN working group (including overlapping RFC-1918 private address 784 space) are on the critical path for "Mesh" softwires. Other 785 encapsulations, like IPv6/IPv6, IPv4/IPv4 or IP-only LAN Service 786 (IPLS) as defined in the L2VPN working group, are nice to have but 787 not on the critical path.There is no intention to place limits on 788 additional encapsulations beyond those explicitly mentioned in this 789 specification. 791 4. Security Considerations 793 Security considerations specific to the "Hubs and Spokes" and "Mesh" 794 models appear in those sections of the document. 796 As with any tunneling protocol, using this protocol may introduce a 797 security issue by circumventing a site security policy implemented as 798 ingress filtering, since these filters will only be applied to STH AF 799 IP headers. 801 5. IANA Considerations 803 There are no IANA actions requested in this specification. 805 6. Changes from -01 807 1. Detailed mailing list comments from Jordi Palet Marinez 808 (2006/03/07). 810 2. Detailed mailing list comments from Pekka Savola (2006/05/03). 812 7. Changes from -00 814 1. Individual-draft authors moved to Authors section, and added an 815 acknowledgements section. 817 2. Detailed mailing list comments from Alain Baudot (2005/12/20). 819 3. Detailed mailing list comments from Pekka Savola (2005/12/22). 821 4. Detailed mailing list comments from Laurent Toutain 822 (2005/12/26). 824 5. Detailed mailing list comments from Francis Dupont (editorial) 825 (2005/12/29). 827 6. Detailed mailing list comments from Francis Dupont (non- 828 editorial) (2005/12/29). 830 7. Detailed mailing list comments from Tom Pusateri (2005/12/29). 832 8. Detailed mailing list comments from Tom Alain Durant 833 (2005/12/30). 835 9. Changed all occurances of "HGW" to "CPE" and added definitio 837 10. Removed all occurances of "TEP" (which seemed to be a synonym 838 for concentrator anyway). 840 11. Changed all occurances of "ISP" to be "operator". 842 12. Removed all RFC 2119 language from the specification (since it's 843 a problem statement). 845 13. Further linguistic clarificatons and edits (2006/01 and 02) 847 14. Remove Compare and Contrast section after discussion w/ authors 848 (2006/02/19) 850 8. Acknowledgements 852 8.1. Authors 854 These are the principal authors for this document. 856 Xing Li 857 CERNET 858 Room 225 Main Building, Tsinghua University 859 Beijing 100084 860 China 862 Phone: +86 10 62785983 863 Fax: +86 10 62785933 864 Email: xing@cernet.edu.cn 866 Alain Durand 867 Comcast 868 1500 Market st 869 Philadelphia 870 PA 19102 USA 872 Email: Alain_Durand@cable.comcast.com 874 Shin Miyakawa 875 NTT Communications 876 3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku 877 Tokyo 878 Japan 880 Phone: +81-3-6800-3262 881 Fax: +81-3-5365-2990 882 Email: miyakawa@nttv6.jp 883 Jordi Palet Martinez 884 Consulintel 885 San Jose Artesano, 1 886 Alcobendas - Madrid 887 E-28108 - Spain 889 Phone: +34 91 151 81 99 890 Fax: +34 91 151 81 98 891 Email: jordi.palet@consulintel.es 893 Florent Parent 894 Hexago 895 2875 boul. Laurier, suite 300 896 Sainte-Foy, QC G1V 2M2 897 Canada 899 Phone: +1 418 266 5533 900 Email: Florent.Parent@hexago.com 902 David Ward 903 Cisco Systems 904 170 W. Tasman Dr. 905 San Jose, CA 95134 906 USA 908 Phone: +1-408-526-4000 909 Email: dward@cisco.com 911 8.2. Contributors 913 The authors would like to acknowledge the following contributors who 914 provided helpful inputs on earlier versions of this document: Alain 915 Baudot, Hui Deng, Francis Dupont, Rob Evans, Ed Koehler Jr, Erik 916 Nordmark, Soohong Daniel Park, Tom Pusateri, Pekka Savola, Bruno 917 Stevant, Laurent Totain, Bill Storer, Maria (Alice) Dos Santos, Yong 918 Cui, Chris Metz, Simon Barber, Skip Booth, Scott Wainner and Carl 919 Williams. 921 The authors would also like to acknowledge the participants in the 922 Softwires interim meeting in Paris, France (October 11-12, 2005) 923 (minutes are at 924 http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm). 926 The authors would also like to express a special acknowledgement and 927 thanks to Mark Townsley. Without his leadership, persistence, 928 editing skills and thorough suggestions for the document; we would 929 have not have been successful. 931 Tunnel-based transition mechanisms have been under discussion in the 932 IETF for more than a decade. Initial work related to softwire can be 933 found in RFC3053. The earlier "V6 Tunnel Configuration" BOF problem 934 statement [I-D.palet-v6tc-goals-tunneling] includes a reasonable 935 pointer to prior work. 937 9. References 939 9.1. Normative References 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, March 1997. 944 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 945 Translator (NAT) Terminology and Considerations", 946 RFC 2663, August 1999. 948 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 949 Stateless Address Autoconfiguration in IPv6", RFC 3041, 950 January 2001. 952 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 953 Tunnel Broker", RFC 3053, January 2001. 955 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 956 RFC 3972, March 2005. 958 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 959 for IPv6 Hosts and Routers", RFC 4213, October 2005. 961 9.2. Informative References 963 [I-D.bellovin-useipsec] 964 S, "Guidelines for Mandating the Use of IPsec, 965 draft-bellovin-useipsec-04", September 2005. 967 [I-D.durand-naptr-service-discovery] 968 A, ""Service Discovery using NAPTR records in DNS", 969 draft-durand-naptr-service-discovery-00", October 2004. 971 [I-D.ietf-v6ops-ipsec-tunnels] 972 P, ""Using IPsec to Secure IPv6-in-IPv4 Tunnels", 973 draft-ietf-v6ops-ipsec-tunnels-01", August 2005. 975 [I-D.palet-v6ops-solution-tun-auto-disc] 976 J, ""IPv6 Tunnel End-point Automatic Discovery Mechanism", 977 draft-palet-v6ops-solution-tun-auto-disc-01", 978 October 2004. 980 [I-D.palet-v6ops-tun-auto-disc] 981 J and M, ""Analysis of IPv6 Tunnel End-point Discovery 982 Mechanisms", draft-palet-v6ops-tun-auto-disc-03", 983 January 2005. 985 [I-D.palet-v6tc-goals-tunneling] 986 J, ""Goals for Tunneling Configuration", 987 draft-palet-v6tc-goals-tunneling-00", February 2005. 989 Author's Address 991 Spencer Dawkins (editor) 992 Huawei Technologies (USA) 993 1700 Alma Drive, Suite 100 994 Plano, TX 75075 995 US 997 Phone: +1 972 509 0309 998 Fax: +1 469 229 5397 999 Email: spencer@mcsr-labs.org 1001 Intellectual Property Statement 1003 The IETF takes no position regarding the validity or scope of any 1004 Intellectual Property Rights or other rights that might be claimed to 1005 pertain to the implementation or use of the technology described in 1006 this document or the extent to which any license under such rights 1007 might or might not be available; nor does it represent that it has 1008 made any independent effort to identify any such rights. Information 1009 on the procedures with respect to rights in RFC documents can be 1010 found in BCP 78 and BCP 79. 1012 Copies of IPR disclosures made to the IETF Secretariat and any 1013 assurances of licenses to be made available, or the result of an 1014 attempt made to obtain a general license or permission for the use of 1015 such proprietary rights by implementers or users of this 1016 specification can be obtained from the IETF on-line IPR repository at 1017 http://www.ietf.org/ipr. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights that may cover technology that may be required to implement 1022 this standard. Please address the information to the IETF at 1023 ietf-ipr@ietf.org. 1025 Disclaimer of Validity 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1030 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1031 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1032 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Copyright Statement 1037 Copyright (C) The Internet Society (2006). This document is subject 1038 to the rights, licenses and restrictions contained in BCP 78, and 1039 except as set forth therein, the authors retain all their rights. 1041 Acknowledgment 1043 Funding for the RFC Editor function is currently provided by the 1044 Internet Society.