idnits 2.17.00 (12 Aug 2021) /tmp/idnits16847/draft-guo-softwire-sc-discovery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 4324 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 == Outdated reference: draft-ietf-v6ops-incremental-cgn has been published as RFC 6264 == Outdated reference: draft-ietf-softwire-ipv6-6rd has been published as RFC 5969 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dayong Guo 2 Internet Draft Sheng Jiang 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 Expires: January 14, 2011 Brian Carpenter 5 University of Auckland 6 July 12, 2010 8 Softwire Concentrator Discovery Using DHCP 10 draft-guo-softwire-sc-discovery-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 14, 2011. 29 Copyright Notice 31 Copyright (c) 2010 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Abstract 46 Several types of Carrier Grade NATs have been proposed to simplify 47 IPv4/IPv6 transition of the edge network by integrating tunnels and 48 NAT. A very common scenario is that many users set up softwires to a 49 softwire concentrator for public or private access services. In order 50 to establish softwires successfully, a new mechanism is required to 51 enable users in the edge network to discover the information of the 52 concentrator. This document describes how a host or Customer Premises 53 Equipment discovers the remote softwire concentrator or CGN in a hub 54 and spoke network using DHCP. Based on two new Softwire Concentrator 55 Discovery DHCP Options, proposed in the document, a user can obtain 56 the information of the softwire concentrator or CGN and then set up a 57 tunnel to it. 59 Table of Contents 61 1. Introduction................................................3 62 2. Terminology.................................................4 63 3. DHCP Solution Overview for Softwire Concentrator Discovery....4 64 4. DHCPv4 Softwire Concentrator Discovery (SCD) Option...........5 65 4.1. Suboptions in DHCPv4 SCD Option.........................6 66 4.1.1. Protocol Type Suboption............................7 67 4.1.2. GRE Key Suboption..................................7 68 5. DHCPv6 Softwire Concentrator Discovery (SCD) Option...........7 69 5.1. Suboptions in DHCPv6 SCD Option.........................8 70 5.1.1. Protocol Type Suboption............................9 71 5.1.2. Prefix Suboption..................................10 72 5.1.3. GRE Key Suboption.................................10 73 6. Illustration Examples.......................................11 74 6.1. Example 1: Incremental CGN scenario....................11 75 6.2. Example 2: two CGN in DS lite scenario.................11 76 7. Security Considerations.....................................11 77 8. IANA Considerations........................................12 78 8.1. Tunnel Types..........................................12 79 8.2. DHCPv4 SCD Suboption Types.............................12 80 8.3. DHCPv6 SCD Suboption Types.............................13 81 9. Acknowledgments............................................13 82 10. Change Log [RFC Editor please remove]......................13 83 11. References................................................13 84 11.1. Normative References..................................13 85 11.2. Informative References................................14 87 1. Introduction 89 Transition is an important factor for user experience in IPv4 and 90 IPv6 coexistence phase. The transition of the edge network is the 91 most complicated because it is near lots of users and uses multiple 92 network technologies. Recently, several types of Carrier-Grade-NATs 93 (CGNs) have been proposed to simplify IPv4/IPv6 transition of the 94 edge network by integrating tunnels and NAT. Incremental CGN 95 [I-D.ietf-v6ops-incremental-cgn] and 6rd [I-D.ietf-softwire-ipv6-6rd] 96 and describes how dispersed IPv6 users bridge with the IPv6 Internet 97 by tunnel spanning ipv4 infrastructure. The dual-stack lite 98 technology [I-D.ietf-softwire-dual-stack-lite] is intended for 99 maintaining connectivity to legacy IPv4 devices and networks using 100 IPv4-over-IPv6 softwires while a service provider deploys an IPv6- 101 only network. A very common scenario is that many users set up 102 softwires or tunnels to a softwire concentrator for public or private 103 access services. 105 The aforementioned scenarios have been abstracted as hub and spoke 106 networks in the IETF Softwire working group, and several 107 encapsulation techniques have been defined [RFC4925] [RFC5512]. 108 [RFC5571] discloses a mechanism in mesh network by BGP extension for 109 users to discover the information of a tunnel end point. However, the 110 nodes in an edge network do not have BGP capability generally. Manual 111 configuration is not suitable because the address and other attribute 112 of the concentrator may change. A new mechanism is required to enable 113 users in edge network to discover the information of the concentrator 114 automatically. 116 In order to establish a softwire successfully, users must know the 117 information of a softwire concentrator or CGN, such as address, 118 tunnel type. Additionally, the discovery process may also support 119 multiple protocol type in tunnel, load-sharing and recovery from a 120 single point of failure. 122 Since ISPs may use different softwire technologies, an ISP- 123 independent CPE should support as many as possible potential softwire 124 technologies and be able to auto discovery which softwire 125 technologies is in use. Even within a single ISP, different softwire 126 technologies may also use to differentiate customers, e.g., support 127 of secured encapsulation for some customers and plain IP-in-IP 128 encapsulation for others. 130 For scalability and stability purposes, customers may be assigned 131 different/multiple softwire concentrators through the discovery 132 mechanism. 134 The Dynamic Host Configuration Protocol (DHCP [RFC2131], [RFC3315]) 135 is widely used in edge networks to enable auto-configuration. This 136 document extends DHCP to support discovery of a softwire concentrator 137 or CGN. This mechanism is general for 6rd, incremental CGN, DS-Lite 138 and Port-range Router [I-D.boucadair-port-rang]. It can also be 139 extended to support the discovery of other concentrators with 140 tunnels. 142 In the absence of DHCP, PPP or Router Advertisements could be used to 143 find a softwire concentrator or CGN automatically, but this document 144 does not discuss these methods in detail. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC2119 [RFC2119]. 152 3. DHCP Solution Overview for Softwire Concentrator Discovery 154 In order to support softwire concentrator or CGN discovery, two new 155 DHCP options are defined respectively for DHCPv4 and DHCPv6. They 156 have the identical structure apart from address length. 158 When a DHCP server answers a client request message, softwire 159 concentrator information can be carried in a DHCP reply message. Thus 160 a client is configured the address and other attributes of a softwire 161 concentrator or CGN and can automatically set up a tunnel. 163 DHCP server decides to attach SCD option based on policy. One choice 164 is to respond only if the client requests the SCD option; another is 165 to append it to every reply no matter the client requests the SCD 166 option or not. 168 For load sharing or single-point failure recovery purposes, a DHCPv4 169 reply message may carry multiple instances in a single DHCPv4 SCD 170 option; a DHCPv6 reply message may carry more than one DHCPv6 SCP 171 options. 173 Section 4 defines a new DHCPv4 Softwire Concentrator Discovery (SCD) 174 option while Section 5 defines DHCPv6 SCD option. Section 4.1 defines 175 sub-options that apply to DHCPv4 SCD option while Section 5.1 defines 176 sub-options that apply to DHCPv6 SCD option. 178 4. DHCPv4 Softwire Concentrator Discovery (SCD) Option 180 The DHCPv4 Softwire Concentrator Discovery (SCD) Option is mainly 181 used when an IPv6 host or CPE in an IPv4 ISP network wants to obtain 182 an IPv4 address of an IPv6 access point or an incremental CGN. The 183 Option is carried in DHCPv4. 185 A DHCPv4 message can carry only one DHCPv4 SCD Option. Multiple 186 instances can be concatenated in the DHCPv4 SCD Option, as follow: 188 |<----Instance1---->|<----Instance2---->| 189 Code Len Len Data Len Data 190 +------+------+------+------------+------+------------+-- 191 | TBD1 | n | n1 | data1... | n2 | data2... | ... 192 +------+------+------+------------+------+------------+-- 194 The DHCPv4 SCD Option is structured as follows: 196 0 1 2 3 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Code | Len | Instance1-Len | Tunnel Type | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Preference | Softwire Concentrator or CGN Address | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | cont. | | 204 +-+-+-+-+-+-+-+-+ Instance1's Suboptions | 205 . . 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Instance2-Len | | 208 +-+-+-+-+-+-+-+-+ Instance2-Data | 209 . . 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 . Instance n . 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Code TBD1. 216 Len n + Len1 + Len2 + ... + Len n. 218 Instance-Len 6 + length of Instance's sub options in octets. 220 Tunnel Type Tunnel type which users connect to softwire 221 concentrators or CGN. A few initial value 222 assignments, like L2TPv2, GRE, ISATAP, 6to4, 6rd, 223 IPSec and other IP in IP, is listed in Section 8 224 IANA consideration. 226 Preference This indicates the preference level for a softwire 227 concentrator or CGN. 0 is the highest. When 228 receiving multiple instances, the user chooses a 229 primary softwire concentrator among them based on 230 the preference. The others are backup softwire 231 concentrators. The service provider assigns 232 different preference for each softwire concentrator 233 to support traffic engineering. 235 Softwire Concentrator or CGN Address The outer layer IPv4 236 address of softwire concentrator, which is used to 237 establish tunnel. 239 Sub Options An optional, variable length field which is defined 240 in Section 4.1. 242 4.1. Suboptions in DHCPv4 SCD Option 244 The suboptions defined in this section can be applied to DHCPv4 SCD 245 option, defined above. They are used to configure the complementary 246 tunnel information. 248 The DHCPv4 SCD suboption is structured in TLV style as follows: 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Suboption Type| Suboption Len | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 . Suboption Value (Variable) . 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 * DHCPv4 SCD Suboption Type (1 octet): each suboption type 259 defines a certain property about the tunnel. The following are 260 the types defined in this document: 262 - Protocol Type: suboption type = 0 264 - GRE Key: suboption type = 1 266 New suboptions may be defined in the future. Any unknown 267 suboptions MUST be ignored and skipped. 269 * Suboption Length (1 octet): the total number of octets of the 270 suboption value field. 272 * Suboption Value (variable): encodings of the value field depend 273 on the suboption type as enumerated above. 275 The following sub-sections define the encoding in detail. 277 4.1.1. Protocol Type Suboption 279 This suboption designates which protocol is encapsulated in tunnel. 281 0 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type = 0 | Len = 2 | Protocol Type | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 287 The Protocol Type field is defined in [IANA-ET] as ETHER TYPEs. The 288 most used protocols are IPv4 (0x0800) and IPv6 (0x86dd). 290 4.1.2. GRE Key Suboption 292 When the tunnel type is GRE, this suboption may be contained. 294 0 1 2 3 295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type = 1 | Len = 4 | GRE Key | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | GRE Key (cont.) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 GRE Key: 4-octet field [RFC2890] that is generated by the 303 Softwire Concentrator or CGN. If the client receives the GRE Key 304 suboption, the key MUST be inserted into the GRE encapsulation 305 header of the payload packets sent by the client to the Softwire 306 Concentrator or CGN. It is used for identifying extra context 307 information about the received payload. The payload packets 308 without the correspondent GRE key or with an unmatched GRE Key 309 will be silently dropped. 311 5. DHCPv6 Softwire Concentrator Discovery (SCD) Option 313 The DHCPv6 Softwire Concentrator Discovery (SCD) Option is mainly 314 used when an IPv4 host or CPE in an IPv6 ISP network wants to learn 315 an IPv6 address of an IPv4 access point or a DS-lite CGN. The Option 316 is carried in DHCPv6. 318 A DHCPv6 Reply message can carry more than one SCD Options. 320 The DHCPv6 SCD Option is structured as follows: 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Option_SCD | Option-len | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 | Softwire Concentrator or CGN Address | 329 | | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Tunnel Type | Preference | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 334 . Sub Options . 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Option-code Option_SCD (TBD2). 339 Option-len 18 + length of sub options in octets. 341 Softwire Concentrator or CGN Address The outer layer IPv6 342 address of softwire concentrator, which is used to 343 establish tunnel. 345 Tunnel Type Tunnel type which users connect to softwire 346 concentrators or CGN. A few initial value 347 assignments, like L2TPv2, GRE, IPSec and IP in IP, 348 is listed in Section 8 IANA consideration. 350 Preference This indicates the preference level for a softwire 351 concentrator or CGN. 0 is the highest. When 352 receiving multiple options, user chooses a primary 353 softwire concentrator among them based on the 354 preference. The others are backup softwire 355 concentrators. The service provider assigns 356 different preference of each softwire concentrator 357 to support traffic engineering. 359 Sub Options An optional, variable length field is defined in 360 Section 5.1. 362 5.1. Suboptions in DHCPv6 SCD Option 364 The suboptions defined in this section can be applied to DHCPv6 SCD 365 option, defined above. They are used to configure the complementary 366 tunnel information. 368 The DHCPv6 SCD suboption is structured in TLV style as follows: 370 0 1 2 3 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Suboption Type | Suboption Len | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 . Suboption Value (Variable) . 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 * DHCPv4 SCD Suboption Type (2 octet): each suboption type 379 defines a certain property about the tunnel. The following are 380 the types defined in this document: 382 - Protocol Type: suboption type = 0 384 - Prefix: suboption type = 1 386 - GRE Key: suboption type = 2 388 New suboptions may be defined in the future. Any unknown 389 suboptions MUST be ignored and skipped. 391 * Suboption Length (2 octet): the total number of octets of the 392 suboption value field. 394 * Suboption Value (variable): encodings of the value field depend 395 on the suboption type as enumerated above. 397 The following sub-sections define the encoding in detail. 399 5.1.1. Protocol Type Suboption 401 This suboption designates which protocol is encapsulated in tunnel. 403 0 1 2 3 404 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type = 0 | Len = 2 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Protocol Type | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 The Protocol Type field is defined in [IANA-ET] as ETHER TYPEs. The 412 most used protocols are IPv4 (0x0800) and IPv6 (0x86dd). 414 5.1.2. Prefix Suboption 416 This suboption designates IPv6 prefix which is used to construct 417 internal address of the tunnel. 419 0 1 2 3 420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = 1 | Len | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Prefix Len | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 426 . IPv6 Prefix | Padding . 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Len: total length of the prefix and padding fields in octets. 431 Prefix Len: Length for this prefix in bits. 433 IPv6 Prefix: IPv6 prefix allocated to the client to construct 434 internal address of the tunnel. 436 Padding: additional 0~7 bits MUST be padded at the end of IPv6 437 Prefix field when the value in Prefix Len field is not a 438 multiple of 8-bit. The padding bits SHOULD be set as 0. 440 The semantics of the value field is determined by the tunnel type. 441 For example, a client can obtain IPv6 Prefix of ISATAP tunnel by this 442 suboption in DHCPv6 SDC Option. 444 5.1.3. GRE Key Suboption 446 When the tunnel type is GRE, this suboption may be contained. 448 0 1 2 3 449 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type = 2 | Len = 4 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | GRE Key | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 GRE Key: 4-octet field [RFC2890] that is generated by the 457 Softwire Concentrator or CGN. If the client receives the GRE Key 458 suboption, the key MUST be inserted into the GRE encapsulation 459 header of the payload packets sent by the client to the Softwire 460 Concentrator or CGN. It is used for identifying extra context 461 information about the received payload. The payload packets 462 without the correspondent GRE key or with an unmatched GRE Key 463 will be silently dropped. 465 6. Illustration Examples 467 6.1. Example 1: Incremental CGN scenario 469 As an example, an incremental CGN with IP address 192.0.2.1 and 470 L2TPv2 tunnel support is deployed in an IPv4 ISP network. The CGN 471 information is stored in a DHCPv4 server. When a dual stack user in 472 the network wants to connect IPv6 Internet, it will send a DHCPv4 473 request message to the DHCP server to obtain the CGN information. The 474 DHCP server replies with a SCD option. The parameters in the SCD 475 option are "CGN address = 192.0.2.1, tunnel type = 1, preference = 476 80". After the user receives the option, it can set up an L2TPv2 477 tunnel with the CGN. 479 6.2. Example 2: two CGN in DS lite scenario 481 In another example scenario, there are two DS lite CGNs deployed in 482 order to provide redundancy and load balancing. DS lite CGN1 is 483 2001:db8:a::1, the other CGN2 is 2001:db8:b::1. Both of them support 484 IPv4 in IPv6 tunnel. The preference of each CGN is decided by the 485 network management policy. A user may get two SCD options, one 486 describes CGN1 "CGN address = 2001:db8:a::1, tunnel type = 3, 487 preference = 80" and the other describes CGN2 "CGN address = 488 2001:db8:b::1, tunnel type = 3, preference = 255". The user should 489 establish an IPv4 in IPv6 tunnel with the CGN1, which has higher 490 preference. When the CGN1 is down, the user may re-establish tunnel 491 to the CGN2. 493 For the load balancing purpose, another user may receive the options, 494 in which CGN2 has the higher preference value. The user may set CGN2 495 as its primary CGN. 497 7. Security Considerations 499 There are two forms of attack using bogus SCD options should be 500 noticeable: 502 1. A wiretap attack, in which a bogus concentrator observes the 503 traffic before pretending to be the real client and sending the 504 traffic to the real concentrator. 506 2. A DoS attack, in which a bogus concentrator is used in some 507 way to create a loop or simply to act as a source of DoS packets. 509 The mechanisms based on DHCPv6 are all vulnerable by man-in-middle 510 attacks. Proper use of DHCPv6 auto-configuration facilities 511 [RFC3315], such as AUTH option or Secure DHCPv6 512 [I-D.ietf-dhc-secure-dhcpv6] can prevent these threats, provided that 513 a configuration token is known to both the client and the server. 515 8. IANA Considerations 517 IANA is requested to allocate one DHCPv4 SCD Option code TBD1 and one 518 DHCPv6 Option code TBD2. 520 This document defines three new namespaces: 522 - Tunnel Types 523 - DHCPv4 SCD Suboption Types 524 - DHCPv6 SCD Suboption Types 526 8.1. Tunnel Types 528 Section 4 & 5 defines the following Tunnel Types, which should 529 assigned by IANA for use within DHCPv4 & DHCPv6 SCD Option. IANA set 530 up a registry for "Tunnel Types for DHCP SCD Option". This is a 531 registry of one-octet values (0-255), to be assigned on a first-come, 532 first-served basis. The initial assignments are as follows: 534 Tunnel Name Type 535 --------------- ----- 536 Reserved 0 537 L2TPv2 1 538 GRE 2 539 IP-in-IP 3 540 ISATAP 4 541 6to4 5 542 6rd 6 543 IPsec 7 545 8.2. DHCPv4 SCD Suboption Types 547 Section 4.1 defines the following SCD Suboption Types, which should 548 assigned by IANA for use within DHCPv4 SCD Option. IANA set up a 549 registry for "DHCPv4 SCD Suboption Types". This is a registry of one- 550 octet values (0-255), to be assigned on a first-come, first-served 551 basis. The initial assignments are as follows: 553 Tunnel Name Type 554 --------------- ----- 555 Protocol Type 0 556 GRE Key 1 558 8.3. DHCPv6 SCD Suboption Types 560 Section 5.1 defines the following SCD Suboption Types, which should 561 assigned by IANA for use within DHCPv6 SCD Option. IANA set up a 562 registry for "DHCPv6 SCD Suboption Types". This is a registry of one- 563 octet values (0-255), to be assigned on a first-come, first-served 564 basis. The initial assignments are as follows: 566 Tunnel Name Type 567 --------------- ----- 568 Protocol Type 0 569 Prefix 1 570 GRE Key 2 572 9. Acknowledgments 574 The authors would like to thank Wei Cao, Huawei, Bernie Volz, Cisco 575 for valuable comments. 577 10. Change Log [RFC Editor please remove] 579 draft-guo-softwire-sc-discovery-00, original version, 2009-06-23. 581 draft-guo-softwire-sc-discovery-01, revised for protocol type, 2009- 582 07-13. 584 draft-guo-softwire-sc-discovery-02, revised after comments at IETF75 585 and comments on the maillist, 2009-10-26. 587 draft-guo-softwire-sc-discovery-03, minor update, 2010-03-05. 589 draft-guo-softwire-sc-discovery-04, revised after comments at IETF77 590 and comments on the maillist, 2010-07-12. 592 11. References 594 11.1. Normative References 596 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 600 March 1997. 602 [RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 603 RFC 2890, September 2000. 605 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 606 IPv6", RFC3315, July 2003. 608 [RFC5512] P. Mohapatra, E. and Rosen, "The BGP Encapsulation 609 Subsequent Address Family Identifier (SAFI) and the BGP 610 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 612 [RFC5571] B. Storer, et al., "Softwire Hub & Spoke Deployment 613 Framework with L2TPv2", RFC 5571, June 2009. 615 11.2. Informative References 617 [RFC4925] X. Li, S. Dawkins, D. Ward, and A. Durand, "Softwire 618 Problem Statement", RFC 4925, July 2007. 620 [I-D.ietf-softwire-dual-stack-lite] 621 A. Durand, R. Droms, B. Haberman, and J. Woodyatt, "Dual- 622 stack lite broadband deployments post IPv4 exhaustion", 623 draft-ietf-softwire-dual-stack-lite, work in progress, 624 March 2010. 626 [I-D.ietf-v6ops-incremental-cgn] 627 S. Jiang, D. Guo, and B. Carpenter, "An Incremental 628 Carrier-Grade NAT (CGN) for IPv6 Transition" draft-ietf- 629 v6ops-incremental-cgn, work in progress, June 2010. 631 [I-D.ietf-dhc-secure-dhcpv6] 632 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 633 ietf-dhc-secure-dhcpv6, work in progress, June 2010. 635 [I-D.ietf-softwire-ipv6-6rd] 636 Townsley W., et al., "IPv6 via IPv4 Service Provider 637 Networks (6rd)", draft-ietf-softwire-ipv6-6rd, (work in 638 progress), March 2010. 640 [I-D.boucadair-port-rang] 641 B. Storer, et al., "IPv4 Connectivity Access in the Context 642 of IPv4 Address Exhaustion", draft-boucadair-port-range- 643 02.txt, work in progress, July 2009. 645 [IANA-ET] "Ether Types", http://www.iana.org/assignments/ethernet- 646 numbers. 648 Author's Addresses 650 Dayong Guo 651 Huawei Technologies Co., Ltd 652 Huawei Building, No.3 Xinxi Rd., 653 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 654 P.R. China 655 Email: guoseu@huawei.com 657 Sheng Jiang 658 Huawei Technologies Co., Ltd 659 Huawei Building, No.3 Xinxi Rd., 660 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 661 P.R. China 662 Email: shengjiang@huawei.com 664 Brian Carpenter 665 Department of Computer Science 666 University of Auckland 667 PB 92019 668 Auckland, 1142 669 New Zealand 670 Email: brian.e.carpenter@gmail.com