idnits 2.17.1 draft-palet-softwires-ats6-01.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 on line 1625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1615. ** 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 : ---------------------------------------------------------------------------- ** There are 46 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (January 18, 2006) is 6673 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) == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '8') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '9') (Obsoleted by RFC 4861) == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipsec-tunnels-01 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Palet 3 Internet-Draft M. Diaz 4 Expires: July 22, 2006 Consulintel 5 January 18, 2006 7 Automatic Tunneling Setup for/with IPv6 8 draft-palet-softwires-ats6-01.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 July 22, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document presents the basis for a procedure that enables a host 42 or router to automatically setup an IPvX in IPvY tunnel. Basically, 43 the document considers several scenarios, from the most common today 44 "dominant IPv4" networks to new "dominant IPv6" networks, which can 45 even support the use of multicast. 47 A basic requirement is that the host or router is a dual stack node 48 and it will have either native IPv4-only access (dominant IPv4 49 network) or native IPv6-only access (dominant IPv6 network). 50 Consequently, either IPv6 will be transported in the existing IPv4- 51 only infrastructure, or IPv4 will be transported in the existing 52 IPv6-only infrastructure. Other combinations are possible, such as 53 IPv6 in IPv6 (for example to support IPv6 multicast in an IPv6- 54 unicast-only infrastructure). 56 The procedure follows the work from [1], [2], [3], [4] and mainly 57 [5], trying to be compliant with the requirements enumerated in those 58 documents. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Sofwire Concentrator Discovery state . . . . . . . . . . . 8 69 5.3. Tunnel Setup Request state . . . . . . . . . . . . . . . . 8 70 5.4. Authenticated (Basic Tunnel) state . . . . . . . . . . . . 8 71 5.5. Authentication and Handshake state . . . . . . . . . . . . 9 72 5.6. Authenticated (Extended Tunnel) state . . . . . . . . . . 10 73 5.7. End state . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Authentication and Handshake Options . . . . . . . . . . . . . 10 75 6.1. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2. Dynamic/Static Prefix . . . . . . . . . . . . . . . . . . 11 77 6.3. Keep-Alive Periodicity . . . . . . . . . . . . . . . . . . 11 78 6.4. NAT Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.5. Cyphering Type . . . . . . . . . . . . . . . . . . . . . . 11 80 6.6. Encapsulation Type . . . . . . . . . . . . . . . . . . . . 11 81 7. Protocol Behavior in IPv4-only Infrastructures . . . . . . . . 12 82 7.1. Link-local Addresses . . . . . . . . . . . . . . . . . . . 12 83 7.2. Global IPv6 Address . . . . . . . . . . . . . . . . . . . 13 84 7.2.1. Pre-Auth Realms . . . . . . . . . . . . . . . . . . . 13 85 7.2.2. Non-Auth Realms . . . . . . . . . . . . . . . . . . . 16 86 7.3. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.4. Extended Tunnel . . . . . . . . . . . . . . . . . . . . . 19 88 7.5. Keep-Alive Packets . . . . . . . . . . . . . . . . . . . . 20 89 8. Protocol Behavior in IPv6-only Infrastructures . . . . . . . . 20 90 8.1. Pre-Auth Realms . . . . . . . . . . . . . . . . . . . . . 21 91 8.1.1. Use of IPv4 addresses derived from the IPv6 one 92 (Basic Tunnel) . . . . . . . . . . . . . . . . . . . . 21 93 8.1.2. Use of DHCP (Extended Tunnel) . . . . . . . . . . . . 24 94 8.2. Non-Auth Realms . . . . . . . . . . . . . . . . . . . . . 25 95 8.2.1. Use of IPv4 addresses derived from the IPv6 one 96 (Basic Tunnel) . . . . . . . . . . . . . . . . . . . . 25 97 8.2.2. Use of DHCP (Extended Tunnel) . . . . . . . . . . . . 25 98 8.3. The IPv6-in-IPv6 Case . . . . . . . . . . . . . . . . . . 25 99 8.4. Keep-Alive Packets . . . . . . . . . . . . . . . . . . . . 26 100 8.4.1. IPv4 tunnel in IPv6-only infrastructures . . . . . . . 26 101 8.4.2. IPv6 tunnel in IPv6-only infrastructures . . . . . . . 26 102 9. Signaling Packets . . . . . . . . . . . . . . . . . . . . . . 26 103 9.1. A&H Packet . . . . . . . . . . . . . . . . . . . . . . . . 26 104 9.2. ACK Packet . . . . . . . . . . . . . . . . . . . . . . . . 29 105 9.3. NO_ACK Packet . . . . . . . . . . . . . . . . . . . . . . 31 106 10. Signaling Encapsulation . . . . . . . . . . . . . . . . . . . 33 107 11. Peer-to-Peer Optimization . . . . . . . . . . . . . . . . . . 34 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 109 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 110 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 111 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 112 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 113 15.2. Informative References . . . . . . . . . . . . . . . . . . 35 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 115 Intellectual Property and Copyright Statements . . . . . . . . . . 38 117 1. Introduction 119 Today, new IPv6 deployment scenarios, which initially were not 120 considered, are emerging. The deployment of IPv6 is already 121 requiring the usage of an automatic tunneling setup, not only in 122 existing IPv4-only infrastructures, but also of IPv4 tunneling in 123 existing IPv6-only infrastructures. 125 The case for IPv6-only infrastructures is a fact, and consequently 126 IPv4-in-IPv6 tunnels are necessary to support communications of old 127 applications not yet ported to IPv6, in those infrastructures. 129 Such scenarios could be classified basically as: 131 o Pre-authenticated user realms: Those where the user is typically 132 already a customer of the network infrastructure (ISPs, enterprise 133 networks, etc.). This could apply to broadband and narrowband 134 networks where the user has somehow "subscribed" or "registered" 135 for the service before using it, by means of other procedures out 136 of the scope of this document. Possibly they can only use the 137 network because it is authenticated by means of the physical 138 attachment to that network (typically DSL, Cable, PLC, 3GPP, 139 etc.). In this case, the user will have, typically, a given 140 profile in the network, which may have specific configuration 141 parameters for that user. 143 o Non-authenticated user realms: Those where the user is not a pre- 144 authenticated customer of the network, but apply for a (temporary) 145 service, may be even free of charge, such as hot spots, transition 146 services in third party networks, guest in an enterprise network, 147 etc. This is often the case for nomadic users, which change their 148 network attachment point when traveling. In this case, the user 149 will not have, a given profile in the network, so specific 150 configuration parameters for that user will not be available. 152 Some of the scenarios have their own requirements as stated in [1], 153 [2], [3], [4] and [5], which include among other few packet exchanges 154 to setup the tunnel, low overhead, etc. These requirements make 155 necessary a new procedure or protocol to setup a tunnel in an 156 automated fashion. This document presents the basis for such 157 protocol, in order to make possible to a host/router the automatic 158 setup of an IPvX-in-IPvY tunnel. 160 2. Requirements 162 The protocol described in this document is based on the requirements 163 described in [1], [2], [3], [4] and [5], but especially in: 165 o To obtain an IPv6 address in IPv4-only infrastructures or an IPv4 166 address in IPv6-only infrastructures. 168 o To automatically setup an IPv6-in-IPv4, IPv4-in-IPv6 tunnel, or 169 IPv6-in-IPv6 tunnel, depending on the user scenario. 171 o To automatically setup and activate the tunnel. 173 o Low overhead on communications. 175 o Low overload on the user device. 177 o Lightweight deployment (minimal infrastructure changes and 178 overhead). 180 o NAT/PAT and Firewall traversing. 182 o To authenticate the user. 184 In addition, allows several optimizations and enhancements, such as 185 the possibility to assign to the user a stable addresses or prefixes 186 (by means of the embedded signaling protocol, or external protocols 187 such as DHCP/DHCPv6/DHCP-PD), rebuilding the tunnel if the IP address 188 changes, renumbering of the tunnel to match the delegated prefix, 189 NAT/PAT auto-detection, and the support for alternative 190 encapsulations. 192 3. Assumptions 194 The solution proposed is based on the following assumptions: 196 o The SC (Softwire Concentrator, according to the softwire 197 terminology) is discovered by other means before starting the 198 tunnel setup, or it is manually configured. 200 o The user host/router (SI, Softwire Initiator, client) is pre- 201 registered within the domain by any valid mean. Note that a 202 registered user is not the same as an authenticated user. 204 o Registered user means, in this context, that this user has some 205 kind of identifier (which is assigned during the registration 206 process) in order to access the network, and may be other 207 associated profile information (name, authentication method, 208 etc...). It could be an anonymous user, in such case the 209 identifier could be just "anonymous". 211 o The SC, either intra or inter networks, will be reachable by at 212 least one of the available encapsulation mechanisms. This for 213 example, ensures the support of NAT/PAT traversal regardless of 214 the type of NAT (symmetric, full-conned, etc). 216 4. Scenarios 218 The following scenarios are considered candidate targets to take 219 advantage of the procedure described in this document. 221 1. Pre-authenticated user realms (from now on, Pre-Auth). Those 222 realms where the user is already authenticated, typically being 223 "customer" of the network infrastructure (ISPs, enterprise 224 networks, etc.). This could apply to broadband and narrowband 225 networks where the user has somehow "signed on" before using the 226 service, by means of other procedures, which are out of the scope 227 of this document. Possibly can only use the network because it 228 is authenticated by means of the physical attachment to the 229 network. Examples of this could be: 231 * Cellular networks such as 3GPP, were IPv4-only or IPv6-only 232 infrastructure is available. 234 * ISP networks (xDSL, Cable, PLC, PSTN, ISDN, etc.). 236 * Enterprise or similar "closed" networks (could be almost 237 equivalent to the ISP case), even if they are connected to 238 Internet via upstream providers. 240 2. Non-authenticated user realms (from now on, Non-Auth): Realms 241 where the user is registered but not authenticated yet. This may 242 be the case for users that apply for a temporary service, may be 243 free of charge, such as a hot spot, transition services in third 244 party networks, guest visitors in an enterprise network, etc. 245 This is often the case for nomadic users, which change their 246 network attachment point when traveling. A concrete example of 247 this scenario could be: 249 * Users with IPv4 connectivity from a hot spot or ISP (via an 250 hotel network), which does not offer IPv6 support, neither a 251 transition service. The user however could use a transition 252 mechanism by means of a SC located in a third party (nearby) 253 ISP or domain. 255 5. Protocol Description 257 The solution is based on the following state diagram: 259 +--------------+ Pre-Auth 260 +-------->| Tunnel Setup |----------------------+ 261 | | Request | | 262 +-----------+ +--------------+ | 263 | SC | | | 264 | Discovery | | Non-Auth | 265 +-----------+ | | 266 ^ | More capabilities | 267 | | +-----------------+ | 268 | | | | | 269 | v v | v 270 +---------+ +----------------+ +----------------+ 271 | Start | | Authentication | | Authenticated | 272 +---------+ | & | | (Basic Tunnel) | 273 | Handshake | +----------------+ 274 +----------------+ ^ | 275 | | | NOT OK | | 276 NOT OK | | | (only Pre-Auth) | | 277 | | +-----------------+ | 278 | | | 279 | | OK | 280 | |(both Pre-Auth & Non-Auth) | 281 | +------------+ | 282 | | | 283 | v | 284 | +-----------------+ | 285 | | Authenticated | | 286 | |(Extended Tunnel)| | 287 | +-----------------+ | 288 | | | 289 v | | 290 +---------+ v | 291 | End |<-------------------------+ 292 +---------+ Tunnel DOWN 294 Figure 1: ATS6 State Diagram 296 5.1. Start State 298 This state only represents the initial state. The initiating device 299 (SI) is ready to start the activation of the tunnel. 301 5.2. Sofwire Concentrator Discovery state 303 Discovery of the SC is out the scope of this specification. It is 304 assumed that the SC is discovered by other external means, or somehow 305 manually configured. However, the discovery mechanism could also be 306 integrated as part in the ATS6 protocol. 308 The document [6] has already analyzed this issue and [7] might be 309 taken into account to be used as the SC discovery mechanism. With 310 regards to those documents, the SC is equivalent to the TEP (Tunnel- 311 End-Point). 313 5.3. Tunnel Setup Request state 315 Once the SC has been discovered, the initiating device (SI) sends a 316 request for the automatic tunnel setup. 318 The request will be done slightly different depending on the 319 available infrastructure and the kind of required tunnel, as 320 described in the next sections. 322 If the device is already authenticated (Pre-Auth), then the tunnel 323 request is automatically accepted and a transition to the 324 Authenticated state is done. On the other hand, if the device is not 325 yet authenticated (Non-Auth), an Authentication and Handshake 326 procedure is required before accepting the tunnel request. 328 5.4. Authenticated (Basic Tunnel) state 330 This state represents the status on which the SI is already 331 authenticated from the perspective of this protocol, coming from 332 either the Tunnel Setup Request state (Pre-Auth users) or the 333 Authentication and Handshake state (Non-Auth users). In this state, 334 the tunnel is kept active (up) on both ends (softwire concentrator 335 and initiator sides). The SI is ready to send/receive data. 337 The SI could send periodically to the SC some kind of keep-alive 338 packets in order to: 340 o Be sure that the tunnel continues up. 342 o Refresh possible timeout in NAT/PAT/Firewall tables. 344 o Allow the SC to do garbage collection. 346 The periodicity of the keep-alive packets could be negotiated between 347 the SC and the SI. This is especially relevant in some cases, such 348 as 3GPP, PSTN, ISDN, typically narrowband links, where the period of 349 these packets could be infinite or a very long value, so that network 350 resources are not wasted (transmitted/received packets, radio 351 spectrum, battery-life, etc.). 353 When the SI does not needs the tunnel anymore, it can transit to the 354 "End" state. 356 If there is a change on the IP address of the SI, then a "Tunnel 357 DOWN" must be forced, implying a transit to the "End" state, in order 358 to keep the SC informed about the new IP address by means of the full 359 ATS6 protocol re-execution, as it may happen also that the SC is a 360 different one. 362 5.5. Authentication and Handshake state 364 This state represents the state where the authentication and 365 handshake process is done. 367 In Non-Auth realms the user may need to be authenticated before 368 setting-up the basic or Extended Tunnel (but it may be an "anonymous" 369 authentication) and the transition to the Authenticated state. 371 In Pre-Auth realms this state implies that the tunnel is already up 372 and ready to send/receive data, but the SI might require extending 373 the tunnel features (type of tunnel different to the one 374 automatically setup, prefix delegation, etc.). To do that the SC 375 could require extra authentication in order to ensure that the SI has 376 the right to obtain the solicited extra-features, to match the user 377 against its pre-defined profile, etc. 379 The actions to be done are: 381 o Only in Non-Auth realms: 383 * Getting the IP address for the SI side to be used with the 384 tunnel. 386 * Setting-up the tunnel on both the SC and SI sides. 388 o Both in Pre-Auth and Non-Auth realms: 390 * User authentication. 392 * Handshake to obtain extra-features on the tunnel. 394 If the negotiation succeeds, the transition is done towards either 395 the Authenticated (Basic Tunnel) state or the Authenticated (Extended 396 Tunnel) state for Non-Auth realms, or towards Authenticated (Extended 397 Tunnel) for Pre-Auth realms. 399 5.6. Authenticated (Extended Tunnel) state 401 This state represents the status on which the SI was successfully 402 authenticated and authorized to set-up a tunnel with extended 403 features, which are not available at the Authenticated (Basic Tunnel) 404 state. The device is ready to send/receive data through the tunnel 405 according to such extended features. 407 The initially available extended features are described in the 408 following sections. 410 5.7. End state 412 This state represents the status on which the SI wants to shut down 413 the tunnel. 415 No messages to the SC are required because the tunnel is discarded 416 when it time-out and no more NS (or similar) have been received. 417 However one END message could be sent to the SC if a change in the IP 418 address is detected in order to speed up the process of discarding 419 the current tunnel, doing garbage collection and setting up a new 420 tunnel. 422 6. Authentication and Handshake Options 424 During the Authentication and Handshake state, the following options 425 are defined by the protocol (other options may be further specified): 427 6.1. IPv6 Prefix 429 The SI could require a specific prefix length (typically /48 or 430 longer) for sub-netting purposes (such as for example the case where 431 the SI is an xDSL CPE). The choices are: 433 o Using DHCPv6 once the Basic Tunnel has been configured. This 434 option assumes that a DHCPv6 client is running on the SI and a 435 DHCPv6 server at the SC. 437 o Using ATS6 built-in capability to delegate the requested prefix to 438 the SI. This simplifies the implementation in the device 439 requiring the tunnel, because DHCPv6 client is not required, 440 saving resources such as memory, additional packet exchanges and 441 so on. 443 This option may be requested by the SI, which also could specify the 444 desired prefix length. The SC could also specify it, regardless of 445 the SI request. 447 6.2. Dynamic/Static Prefix 449 The SI could require that the prefix is a static one instead of 450 dynamic. A static prefix will be delegated only if the user profile 451 has the capability to associate it. 453 6.3. Keep-Alive Periodicity 455 As stated above, the keep-alive packets are useful to find out if the 456 tunnel is up or down (for example in case the IPv4 address has 457 changed), garbage collection and also to refresh the NAT/PAT tables. 458 However, there can be network environments where there is a need to 459 minimize the traffic exchange in order to save cost or resources 460 (example cost of radio resources in 3GPP networks, dial-up or ISDN 461 networks, etc.). In such networks, the periodicity of the keep-alive 462 packets can be set to infinite, which in practice means that no keep- 463 alive packets are delivered at all. Otherwise the period of such 464 packets is assumed to be defined by the SC, but may be also requested 465 by the SI. 467 6.4. NAT Type 469 In some situations the NAT is at the SC side, so the type is well 470 know and the same for all the devices; this is typically the case for 471 3GPP, dial-up, ISDN, among others. In other cases, the NAT type may 472 depend on the device(s) at the SI side. In the first case, there is 473 no need to start a NAT auto-detection procedure, but in both cases 474 the SC should provide the information about if there is a NAT and 475 what type is it. 477 6.5. Cyphering Type 479 All the handshake packets have to be signed in order to guarantee the 480 identity of both, the SC and the SI. This option specify the hash 481 function that need to be used (MD5, SHA1, ...). 483 6.6. Encapsulation Type 485 Different encapsulations are possible (IPv6-in-IPv4, IPv6-in-UDP- 486 IPv4, IPv4-in-IPv6, etc.). The one to be actually used will be 487 defined by the SC (it may depend on the existence of NAT). 489 7. Protocol Behavior in IPv4-only Infrastructures 491 7.1. Link-local Addresses 493 The SI is willing to obtain an IPv6 address, so it makes a link-local 494 address which has embedded both its public IPv4 address and the MAC 495 address, as follows: 497 16 bits 64 bits 32 bits 498 <----> <----------------> <--------> 499 +------+------+------------------+----------+ 500 | FE80 | 0000 | YYYYYYYYYYYYYYYY | XXXXXXXX | 501 +------+------+------------------+----------+ 503 Figure 2: IPv6 Link-local Address Format for the SI 505 XXXXXXXX and YYYYYYYYYYYYYYYY are, respectively, the hexadecimal 506 notation of the IPv4 public address (the one being used by the SI for 507 the interface where the tunnel is required) and the Interface 508 Identifier based on the MAC address, as generated by stateless auto- 509 configuration. 511 If a NAT box is used, the public IPv4 address can be discovered by 512 using STUN [8], which should be available at the SC. At this way the 513 NAT type is also detected, as it will be required in the next steps. 515 Embedding the public IPv4 address into the IPv6 link-local address 516 has the advantage of allowing the SC to know where the IPv6 tunnel 517 should be terminated, without needing to check other internal tables, 518 and consequently there is no need to maintain any new table relating 519 the IPv6 tunnels with the IPv4 addresses, and save the related 520 resources. 522 On the other hand, embedding the MAC address into the link-local has 523 the advantage of allowing identifying each specific node behind a NAT 524 box when each of them is a SI. 526 The SC will also create its own IPv6 link-local address, which will 527 be assumed by the SI to be already setup. The SC link-local is built 528 by embedding the IPv4 address of the SC, which is the only data known 529 by the SI, as follows: 531 80 bits 32 bits 532 <--------------------> <--------> 533 +------+----------------------+----------+ 534 | FE80 | 00000000000000000000 | XXXXXXXX | 535 +------+----------------------+----------+ 537 Figure 3: IPv6 Link-local Address Format for the SC 539 7.2. Global IPv6 Address 541 The basic IPv6 tunnel that the SI builds is automatic in the sense 542 that it does not require manual configuration and it is built by 543 using only a link-local address at each end of the tunnel. On the 544 other hand the global IPv6 address is obtained by means of stateless 545 auto-configuration, once the link-local address of the SI is already 546 setup. 548 Then the SI sends an IPv6-in-IPv4 Router Solicitation (RS) packet [9] 549 to the SC by using the link-local address just made. The RS message 550 is sent as payload, properly encapsulated so it can reach the SC 551 link-local address. 553 From now on, the process follows depending on the type of user's 554 realm. 556 7.2.1. Pre-Auth Realms 558 In this case, the user is already authenticated, so there is no need 559 to handshake for a Basic Tunnel. Once the SC receives the IPv4- 560 encapsulated RS from the SI, a transition to the Authenticated (Basic 561 Tunnel) state is done and it replies with a single IPv4-encapsulated 562 Router Advertisement (RA) packet [9] to the querying device and setup 563 the tunnel. A transition to the "Authenticated" state is done. 565 The SI builds the global IPv6 address with the received prefix plus 566 an Interface Identifier, which is taken from the 64 low-order bits of 567 the link-local address, which have embedded its public IPv4 address. 568 In this way, by observing the global IPv6 address, the SC knows where 569 it has to forward the packets sent to such global IPv6 address. The 570 management of the routing table is hence simplified. 572 If the IPv6 address changes, the global IPv6 address has to be 573 changed also, which is not a problem because the IPv6 tunnel will 574 transition to a down state. 576 Note: Alternatively to this approach, it could be also possible to 577 build the global IPv6 address by means of the stateless auto- 578 configuration, by making the Interface Identifier based on the MAC 579 address of the interface being used. In this way, the IPv4 address 580 will not be embedded into the global IPv6 address, so if there is a 581 change in the IPv4 address, only the link-local address corresponding 582 to the IPv6 tunnel would change, but not the global one. However 583 this approach has the drawback that more routing management has to be 584 used on the SC to update the routing table. 586 Once the RA is received, the SI knows that there is no NAT or that 587 the existing one supports 6in4 or "proto-41" forwarding [11]. 588 Furthermore this fact means that the tunnel has been setup on the SC 589 side. 591 At this point the SI is ready to send/receive data by using its IPv6 592 global address on the Basic Tunnel. If extended capabilities are 593 required, a transition to the Authenticated (Extended Tunnel) state 594 is required, as described in the following sections. 596 If the RA is not received before timing out, the SI will send a new 597 RS and even a third one if required. This will avoid preventing the 598 tunnel creation because either or both RS/RA are lost, for example 599 because bad network conditions. 601 After the third RS, if no RA is returned, the SI understands that 602 some network elements prevent the use of IPv6-in-IPv4 tunneling from 603 the SI to the SC. In this case, the SI starts the detection of the 604 NAT type and public IPv4 address, by means of STUN [8] and repeats 605 the process by using UDP-in-IPv4 encapsulation (i.e., RS_ICMPv6-IPv6- 606 UDP-IPv4). The port number for receiving the packets at the SC needs 607 to be defined, while the port number for receiving packets at the SI 608 is taken from the received packets at the SC. The tunnel setup 609 process is the same, but packets are encapsulated as payload of UDP/ 610 IPv4. 612 Note: It may be explored using the same UDP port as Teredo [10], for 613 certain compatibility. Also other possibilities may be explored 614 here, such as GRE, PPTP, L2TP, etc. priority needs to be fixed. 616 On the other hand, if the SC detects that there is already another 617 tunnel associated to the same public IPv4 address, it means that 618 several SIs are located behind a NAT, and should force an alternative 619 encapsulation to IPv6-in-IPv4 (i.e., IPv6-UDP-IPv4), as this one will 620 be only valid for the first user behind the NAT. 622 This is done, as showed in Figure 7, by forcing the transition to the 623 Authentication and Handshake state. To do that, the SC sends one 624 IPv4-encapsulated RA with the M bit set and it does not include the 625 "Prefix Information" option on the RA. The complete handshake 626 procedure is explained in section 7.3. 628 Below some timing charts depict the packet exchanges in order to 629 clarify the tunnel creation in Pre-Auth realms under different 630 situations. 632 SI SC 633 RS 634 | -------------------> | (Tunnel Request state) 635 | | 636 | RA with prefix | 637 | <------------------- | (Authenticated Basic Tunnel state) 638 | | 640 Figure 4: Basic Tunnel request in Pre-Auth realms with IPv6-in-IPv4 641 support 643 SI SC 644 RS 645 ^ | -------------------> | \ 646 T1 | | | | 647 | | | | 648 v | RS | | 649 ^ | -------------------> | | (Tunnel Request state) 650 T2 | | | | 651 | | | | 652 v | RS | | 653 | -------------------> | | 654 | | / 655 | RA with prefix | 656 | <------------------- | (Authenticated Basic Tunnel state) 657 | | 659 Figure 5: Basic Tunnel request in Pre-Auth realms with IPv6-in-IPv4 660 support (RAs lost) 662 Tx: Timeout for waiting the RA once the RS has been sent. This may 663 be variable and configurable by the implementation. Good values seem 664 to be 1 second for the first and second timeouts (T1 and T2) and 3 665 seconds for the last one (T3). 667 SI SC 668 RS 669 ^ | -------------------> | \ 670 T1 | | | | 671 | | | | 672 v | RS | | 673 ^ | -------------------> | | 674 T2 | | | | 675 | | | | (Tunnel Request state) 676 v | RS | | 677 ^ | -------------------> | | 678 | | | | 679 | | | | 680 T3 | | | | 681 | | | | 682 | | | | 683 v | RS (IPv6-UPD-IPv4) | | 684 | -------------------> | | 685 | | / 686 | RA with prefix | 687 | (IPv6-UPD-IPv4) | 688 | <------------------- | (Authenticated Basic Tunnel state) 689 | | 691 Figure 6: Basic Tunnel request in Pre-Auth realms with no IPv6-in- 692 IPv4 support 694 SI SC 695 RS* 696 | -------------------> | (Tunnel Request state) 697 | | 698 | RA, M=1, no prefix | 699 | <------------------- | (A&H state) 700 | | 702 Figure 7: Basic Tunnel request in Pre-Auth realms with more than one 703 SI behind the same NAT 705 (*) This RS can be IPv6-in-IPv4 or IPv6-UDP-IPv4, according to the 706 type of IPv6-in-IPv4 support or not, as in previous figures. 708 7.2.2. Non-Auth Realms 710 In this case, the users have to be authenticated before being 711 authorized to use the SC, so the SC sends one IPv4-encapsulated RA 712 with the M bit set. Furthermore it does not include the "Prefix 713 Information" option on the RA and a transition to the "Authentication 714 and Handshake" state is done as shown in Figure 7. The complete 715 handshake procedure is explained in section 7.3. 717 If there are more than one SI behind the same NAT, it is mandatory to 718 build the IPv6 tunnel by means of UDP encapsulation, as far the Pre- 719 Auth case above. This negotiation is also done during the A&H state. 721 If the RA is received by the SI, it knows that the there is not NAT, 722 or the existing one supports proto-41 forwarding [11], but user 723 authentication is required to continue. This means the device needs 724 to transit to the Authentication and Handshake state. 726 If the RA is not received before timing out, the SI send again the RS 727 a second and a third time if required. This will prevent that the 728 tunnel is not created because either or both lost RS/RA due to bad 729 network conditions. As for the Pre-Auth case, timeouts may be 730 variable and configurable by the implementation. Good values seem to 731 be 1 second for the first and second timeouts (T1 and T2), and 3 732 seconds for the last one (T3). After the third RS, if no RA is 733 received back, the SI understands that IPv6-in-IPv4 is not supported 734 on the path to the SC. In this case, the SI starts the detection of 735 the NAT type and public IPv4 address, by means of STUN [8] and 736 repeats the process by using UDP encapsulation (i.e., RS_ICMPv6-IPv6- 737 UDP-IPv4). The port number for receiving the packets at the SC needs 738 to be defined, while the port number for receiving packets at the SI 739 is taken from the received packets at the SC. 741 Note: It may be explored using the same UDP port as Teredo [10], for 742 certain compatibility. Also other possibilities may be explored 743 here, such as GRE, PPTP, L2TP, etc. priority needs to be fixed. 745 During the handshake, the SI can request for extending the tunnel 746 capabilities, so a transition to the Authenticated (Extended Tunnel) 747 can be done already, if the authentication succeeds. The transit to 748 the Authenticated (Basic Tunnel) state is only done in case the SI 749 does not request for extended features. 751 7.3. Handshake 753 In this case the desired tunnel will be IPv6-in-IPv4, so the 754 "Authentication and Handshake" packet (A&H) (defined below) could be 755 made by means of sending new ICMPv6 packet/s (unspecified yet) to the 756 SC. The packet/s will contain user identification, authentication 757 and parameter information. The packet exchange between SC and SI 758 will be short in time to keep the process as simple as possible. 760 In Non-Auth realms the SI starts the A&H process but after the SC 761 indicate it is required in "Tunnel Setup Request" state, by means of 762 the M bit in the RA (without Prefix Information), as depicted in 763 Figure 7. 765 In Pre-Auth realms the SI also starts the A&H process at any time 766 from "Authenticated" state. Also it might be possible for the SC to 767 force the A&H from the Tunnel Request state if it detects more than 768 one device behind the same NAT, when it receives the first IPv4- 769 encapsulated RS from a new SI. The A&H process is indicated by means 770 of the M bit being set in the RA (without "Prefix Information"), as 771 shown in Figure 7 above. In this case the SI is not forced to 772 include user's login information because he is already authenticated 773 within the realm. 775 The A&H packet sent by the SI indicates the options that the SI 776 wishes for setting-up the tunnel (i.e., IPv6 tunnel in an IPv4-only 777 infrastructure, IPv4 tunnel in an IPv6-only infrastructure, etc.). 779 Once the SC receives the "A&H Packet", it checks the right or policy 780 of the user at the SC or associated database. If the data match the 781 required policy, the tunnel is activated, modified, or extended with 782 the new requested features. Then the SC sends to the SI an 783 acknowledge (ACK) packet with the setup that is granted (i.e., IPv6- 784 in-IPv4 tunnel, IPv6-UDP-IPv4 tunnel with DHCPv6-PD, etc.). When 785 needed, the SC also sends the RA in order to communicate to the SI 786 the IPv6 prefix needed to build the global IPv6 address (Basic 787 Tunnel) as explained before. 789 If the authentication data is wrong or does not match the necessary 790 credentials, rights, policy, etc., the SC replies with information 791 about what is wrong by means of a NO_ACK packet, in the Packet Type 792 Field (such as authentication, type of query, etc.). Then a 793 transition to the "End" state is done in the Non-Auth case or to the 794 "Authenticated" state in the Pre-Auth case. In the later one, the 795 tunnel continues up but the required extended features are not 796 provided. 798 The following diagram summarized the steps during the Authentication 799 & Handshake phase: 801 SI SC 802 RS* 803 | -------------------> | (Tunnel Request state) 804 | | 805 | RA, M=1, no prefix | 806 | <------------------- | (A&H state) 807 | | 808 | A&H packet | 809 | -------------------> | 810 | | 811 | ACK | \ 812 | <------------------- | | 813 | | | Handshake succeeded 814 | RA (if needed) | | 815 | <------------------- | / 816 | | 817 | NO_ACK | 818 | <------------------- | => Handshake failed 820 Figure 8: Handshake for Non-Auth realms and Pre-Auth realms with more 821 than one SI behind a NAT 823 (*) This RS can be IPv6-in-IPv4 or IPv6-UDP-IPv4, according to the 824 type of NAT as depicted in Figures 5 and 6. 826 The following diagram summarizes the steps during the Authentication 827 & Handshake phase for authenticated users (Pre-Auth or Non-Auth after 828 authentication) willing to extend the Basic Tunnel: 830 SI SC 831 A&H packet 832 | -------------------> | 833 | | 834 | ACK | 835 | <------------------- | ==> Handshake succeeded 836 | | 837 | NO_ACK | 838 | <------------------- | ==> Handshake failed 840 Figure 9: Handshake for Authenticated users requesting for Extended 841 Tunnel 843 7.4. Extended Tunnel 845 The Basic Tunnel might not be enough for the SI because might need to 846 arrange sub-nets or even might require a predefined prefix. For this 847 reason, the SI could initiate the handshake for extending the tunnel 848 capabilities at any time according to the figure 9. 850 One important option available for Extended Tunnels is the prefix 851 delegation. Towards this, during the handshake stage, the SI request 852 a delegated prefix (shorter than 64 bits, typically a /48 one) and 853 the way how it expects to receive it (DHCPv6 or ACK packet which is 854 simpler). 856 Also the SI can request for a dynamic prefix or a static one, 857 according to its needs. If the user has rights to ask for such a 858 feature the SC replies with an ACK packet. Otherwise the SC sends a 859 NO_ACK packet and the process stops. 861 Once the new prefix is received by the SI, the Basic Tunnel which is 862 based on the link-local addresses is renumbered. The tunnel will use 863 the first /64 from the delegated prefix in order to simplify the 864 routing table (I-D.palet-v6ops-point2point) at the SC. 866 7.5. Keep-Alive Packets 868 Once the tunnel is up and running, in IPv4-only infrastructures, the 869 keep-alive packet will be the ICMPv6 Neighbor Solicitation packets 870 [9], being the SC IPv6 link-local address the target and the SI IPv6 871 link-local address the source. The SC must reply with the proper 872 ICMPv6 Neighbor Advertisement packet [9] in order to let know to the 873 SI that the tunnel is still up and also to refresh a possible NAT/PAT 874 table. 876 The default keep-alive periodicity will be 60 seconds. If not keep- 877 alive packets are received at the SC within the configured keep-alive 878 period, the SC will bring down the tunnel and do garbage collection. 880 8. Protocol Behavior in IPv6-only Infrastructures 882 Being the infrastructure IPv6-ready, the "A&H Packet" below described 883 is already directly usable, as it is an IPv6 packet. Consequently, 884 it can be used as described before to establish any kind of tunnels, 885 such as IPv4-in-IPv6, IPv6-in-IPv6, etc., modify them, activate new 886 features, etc. 888 Following a similar philosophy as in the case of IPv4-only 889 infrastructure, the SI that requires IPv4 access, will obtain the 890 IPv4 address in the tunnel itself. There are at least two candidate 891 choices (to be fixed in a new release): 893 o IPv4 address derived from the IPv6 one: By using the global IPv6 894 address used in this communication by the SI, a hash or similar 895 algorithm could be used to create an IPv4 address, probably in the 896 network 10/8. Even if the combination of using the IPv6 global 897 address and the network 10/8 provides a lower probability of 898 address duplication, However it might occur that Duplicate 899 Addresses are generated, it may be necessary/convenient to run a 900 Duplicate Address Detection algorithm at the SC. 902 o DHCP: The SC should either be the DHCP (IPv4) server or relay/ 903 proxy for an external one. DHCPv6 could also be considered, as it 904 could make the process much simpler, but in general DHCPv6 support 905 is weaker. This option is preferred over the previous one, 906 because it avoids the existence of Duplicate Addresses. 908 The procedure in IPv4-only infrastructures is simpler because the 909 native IPv6 infrastructure is already available at the SI, so there 910 is no need to built artificial link-local address like in the case of 911 IPv4-only infrastructure (as they will be already available at every 912 interface). 914 The Basic Tunnel for this case is considered as an IPv4 tunnel where 915 the IPv4 address is derived from the global IPv4 one. If the SI is 916 willing to use and address provided by the SC (either via DHCP or ACK 917 packet), then it will use an IPv4 link-local address [12] to start 918 the Tunnel Request and then will transition to the A&H state to 919 request an address by means of DHCP, as explained below. 921 All the handshake process is done by using the ATS6-ICMPv6 packets 922 because native IPv6 support is available, so there is no need for 923 looking for other protocols in this case. However, it is possible to 924 use other protocols like UDP, TCP, PPP, etc. rather than ICMPv6 to 925 perform the handshake process. 927 8.1. Pre-Auth Realms 929 8.1.1. Use of IPv4 addresses derived from the IPv6 one (Basic Tunnel) 931 The IPv4 address should be generated by an algorithm (to be defined) 932 from the global IPv6 address used in the communication with the SC. 933 This could be done by means of a hash function. 935 In order to simplify several network considerations, such as routing, 936 seems a better approach the use of a 10.0.0.0/8 address. The SC will 937 behave as the default gateway and also NAT for that SI, being the 938 first IPv4 address of the pool (10.0.0.1) the one assigned to the SC. 940 The Tunnel Request is indicated to the SC as a sequence of three 941 predefined-length ICMPv4 ping request packets (6 bytes for the first 942 ping request packet, 7 bytes for the second one and 8 bytes for the 943 third one) as shown in Figure 10. Such ping request packets have as 944 source the IPv4 address extracted from the global IPv6 one (hashing 945 function) and they are directly encapsulated into IPv6 packets (with 946 IPv6 global address as source). 948 Because the user is already authenticated, after receiving the tunnel 949 request, the SC will reply with one ICMPv4 ping reply packet to every 950 ping request, indicating with the last one that the tunnel is already 951 up in the SC side. The SC will extract the SI IPv4 address from the 952 received ICMPv4 ping request packets. When receiving the third 953 ICMPv4 ping reply, the SI understands that the tunnel is ready to 954 send/receive packets and a transition to the Authenticated (Basic 955 Tunnel) state is done. 957 SI SC 958 ICMPv4 ping req. seq. 959 | -------------------> | (Tunnel Request state) 960 | | 961 | ICMPv4 ping rep. seq. | 962 | <------------------- | (Authenticated Basic Tunnel state) 963 | | 965 Figure 10: Basic Tunnel request in Pre-Auth realms for IPv6-only 966 infrastructures 968 If three ICMPv4 ping replies are not received, either because any of 969 them has been lost or not send, the SI will send again the complete 970 sequence of ICMPv4 ping requests, up to two more times, in a similar 971 fashion as for the tunnel request for the IPv4-only infrastructure. 972 The timeouts for the whole ICMPv4 ping reply sequence may be variable 973 and configurable by the implementation. Good values seem to be 1 974 second for the first and second sequence timeouts (T1 and T2) and 3 975 seconds for the last one (T3). 977 SI SC 978 ICMPv4 ping req. seq. 979 ^ | --------------------> | \ 980 T1 | | | | 981 | | | | 982 v | ICMPv4 ping req. seq. | | 983 ^ | --------------------> | | (Tunnel Request state) 984 T2 | | | | 985 | | | | 986 v | ICMPv4 ping req. seq. | | 987 | --------------------> | | 988 | | / 989 | ICMPv4 ping rep. seq. | 990 | <-------------------- | (Authenticated Basic Tunnel state) 991 | | 993 Figure 11: Basic Tunnel request in Pre-Auth realms for IPv6-only 994 infrastructures with lost ping replies 996 If the SC detects that the IPv4 address used by the SI is already 997 used by another one, it will not send any ICMPv4 ping reply. After 998 the third ICMPv4 ping request sequence that has not been replied, the 999 SI understands that there is some trouble with the tunnel request 1000 (i.e., duplicate IPv4 address) and it transitions to the A&H state to 1001 request a tunnel as shown in Figure 12 below. 1003 SI SC 1004 ICMPv4 ping req. seq. 1005 ^ | --------------------> | \ 1006 T1 | | | | 1007 | | | | 1008 v | ICMPv4 ping req. seq. | | 1009 ^ | --------------------> | | 1010 T2 | | | | 1011 | | | | (Tunnel Request state) 1012 v | ICMPv4 ping req. seq. | | 1013 ^ | --------------------> | | 1014 | | | | 1015 | | | | 1016 T3 | | | | 1017 | | | | 1018 | | | | 1019 v | A&H | / 1020 | --------------------> | \ 1021 | | | (A&H state) 1022 | ACK | | 1023 | <-------------------- | | Handshake successful 1024 | | | 1025 | | | 1026 | NO_ACK | | 1027 | <-------------------- | | Handshake unsuccessful 1028 | | / 1030 Figure 12: Basic Tunnel request in Pre-Auth realms for IPv6-only 1031 infrastructures with duplicate IPv4 address 1033 With the ACK packet the SC communicates to the SI how the IPv4 1034 address is provided (DHCP or ACK packet). 1036 8.1.2. Use of DHCP (Extended Tunnel) 1038 If the SI is willing to use an IPv4 address provided from the SC pool 1039 rather than using the one derived from the IPv6 global address, the 1040 tunnel request process is done by using an IPv4 link-local address 1041 (169.254.0.0/16) [12]. After receiving the first ICMPv4 ping request 1042 packet, the SC will realize that it has not to send ping replies and 1043 a transition to the A&H state is done as shown in Figure 12. 1045 Because the user is already authenticated in the network, there is no 1046 need to include in the A&H packet information about the user's login, 1047 but optionally it could be included. 1049 Once the ACK packet coming from the SC is received, the SI which is 1050 requesting an IPv6-in-IPv4 tunnel, need to construct a DHCP request 1051 packet, as it would be done in a LAN. The packet will be 1052 encapsulated in an IPv6 packet, which is sent to the SC. The SC will 1053 then de-capsulate the packet and reply to the DHCP request (either by 1054 a built-in DHCP server or proxing/relaying it). 1056 As the user is already authenticated, the SC delivers an IPv4 address 1057 to the SI, following a pre-defined policy in the DHCP server. The 1058 response DHCP packet will need to be encapsulated in an IPv6 one and 1059 sent to the SI, which will de-capsulate it for configuring its IPv4 1060 address. 1062 This provides a better solution (for example public IPv4 addresses 1063 could be used as the DHCP address pool), but requires DHCP client 1064 support at the SI and DHCP server a the SC side. 1066 Once the process of having a pre-defined IPv4 address if completed, a 1067 transition to the Authenticated (Extended Tunnel) state is done. 1069 8.2. Non-Auth Realms 1071 8.2.1. Use of IPv4 addresses derived from the IPv6 one (Basic Tunnel) 1073 In this case, the SI needs to be authenticated, so a transition to 1074 the A&H state is done by not replying to any ICMPv4 ping request 1075 packet as shown in Figure 12. 1077 Once the ACK is received, the authentication succeeded, and the 1078 tunnel can be considered as activated in both, the SC and the SI 1079 sides, so there is no need for further ICMPv4 reply packets from the 1080 SC. In this case, the IPv4 address is not provided neither via DHCP 1081 nor the ACK packet. 1083 8.2.2. Use of DHCP (Extended Tunnel) 1085 In this case, the SI uses one IPv4 link-local address to initiate the 1086 tunnel request as explained for the IPv4-DCHP/Pre-Auth case. However 1087 it needs to be authenticated, so a transition to the A&H state is 1088 done by not replying to any ICMPv4 ping request packet as shown in 1089 Figure 12. 1091 Once the authentication succeeded, the SC will reply with an ACK 1092 packet indicating that it is ready to receive the a DHCP IPv6- 1093 encapsulated packet from the SI and the process is then continued the 1094 same way as in the Pre-Auth realms case. 1096 8.3. The IPv6-in-IPv6 Case 1098 In IPv6-only infrastructures, it could be needed and IPv6-in-IPv6 1099 tunnel, for example when the infrastructure does not natively support 1100 IPv6 multicast. 1102 In this case the procedure would be as explained in the case of IPv4- 1103 only infrastructures, with the only difference being in the no need 1104 to build the link-local address of the tunnel, as this is already 1105 natively available in this case. Figures 4, 7 and 8 show details 1106 about the tunnel request procedure. 1108 8.4. Keep-Alive Packets 1110 Once the tunnel is up and running in IPv6-only infrastructures, the 1111 type of keep-alive packet will depend on the type of tunnel. 1113 The default keep-alive periodicity will be 60 seconds. If no keep- 1114 alive packets are received at the SC within the configured keep-alive 1115 period, the SC will shut down the tunnel and will do garbage 1116 collection. 1118 8.4.1. IPv4 tunnel in IPv6-only infrastructures 1120 In this type of tunnels the keep-alive will be ICMPv4 ping request 1121 packets, being the destination the SC IPv4 address and the source the 1122 SI IPv4 address configured with the tunnel. The SC must reply in 1123 order to let know the SI that the tunnel is still up. 1125 8.4.2. IPv6 tunnel in IPv6-only infrastructures 1127 In this type of tunnels the keep-alive will be ICMPv6 Neighbor 1128 Solicitation packets [9], being the SC IPv6 link-local address the 1129 target and the SI IPv6 link-local address the source one. The SC 1130 must reply with the ICMPv6 Neighbor Advertisement packet [9] in order 1131 to let know to the SI that the tunnel is still up. 1133 9. Signaling Packets 1135 For signaling the authentication and tunnel setup process, three 1136 types of packets are defined: A&H packet, ACK packet and NO_ACK 1137 packet. These packets are described in the following sections. 1139 9.1. A&H Packet 1141 This IPv6 packet is used to communicate the SC that the user is 1142 willing to build a tunnel (Non-Auth case) or modify/extend the one 1143 already configured with extra-features. The format of such a packet 1144 is as follows: 1146 0 16 31 1147 +-----------------------------------+-----------------------------------+ 1148 | ID Length | Signature Length | 1149 +--------+-------------+------------+-----------------+--------+--------+ 1150 | Packet | Tunnel | | Signat.| Encaps.| 1151 | Type | Type | Reserved | Type | Type | 1152 +--------+-------------+------------------------------+--------+--------+ 1153 | USER_ID | 1154 +-----------------------------------------------------------------------+ 1155 | Random | 1156 +-----------------------------------------------------------------------+ 1157 | Signature | 1158 +-----------------------------------------------------------------------+ 1160 Figure 13: ATS6 A&H Packet 1162 The Parameters are used to define the authentication method, what 1163 extra-features are required, etc. and their meanings are as follows: 1165 o ID Length (16 bits): The length of the USER_ID field. 1167 o Signature Length (16 bits): The length of Signature field. 1169 o Packet Type (4 bits): Information about the packet type (A&H, ACK 1170 or NO_ACK). 1172 o Tunnel Type (5 bits): The required tunnel type is indicated by 1173 setting-up every flag in this field, as follows (from most 1174 significant to least significant bits): 1176 * I: Type of native infrastructure (set for IPv4, unset for 1177 IPv6). 1179 * O: Type of overlay infrastructure (set for IPv4, unset for 1180 IPv6). 1182 * T: Type of tunnel (set for Basic, unset for Extended). 1184 * D: Type of desired IPv6/IPv4 prefix/address (set for Dynamic, 1185 unset for Static). 1187 * P: Type of IPv6/IPv4 prefix/address provision (set for DHCP, 1188 unset ACK packet). 1190 * Some examples provided below: 1192 * I O T D P 1193 * 1 0 1 x x -> Basic IPv6 tunnel in IPv4-only infrastructure 1195 * 1 0 0 0 1 -> Extended IPv6 tunnel in IPv4-only infrastructure, 1196 with DHCPv6-PD 1198 * 0 1 1 x x -> Basic IPv4 tunnel in IPv6-only infrastructure 1200 * 0 0 1 x x -> Basic IPv6 tunnel in IPv6-only infrastructure 1202 * 0 0 0 0 0 -> Tunnel is down, either because the SI does not 1203 need any more the tunnel, or the native infrastructure IP 1204 address has changed. In any case, a transition to the END 1205 state is forced in both, the SI and SC. 1207 o Reserved (13 bits): Reserved bits for future use. 1209 o Signature Type (4 bits): The type of signature to be used in the 1210 handshake process. 1212 o Encapsulation Type (6 bits): The required encapsulation type is 1213 indicated by setting-up every flag in this field. The meaning of 1214 the flags (from most significant to least significant bits) are as 1215 follow (set for required, unset not required): 1217 * G: GRE 1219 * I: IP 1221 * L: L2TP 1223 * P: PPP 1225 * T: PPTP 1227 * U: UDP 1229 * Some examples provided below (Type of Tunnel indicated by the 1230 Tunnel Type field above): 1232 * G I L P T U 1234 * 0 1 1 0 1 1 -> Tunnel using L2TP/PPTP/UDP (example, IPv6/L2TP/ 1235 PPTP/UDP/IPv4) 1237 * 0 1 0 0 0 0 -> Tunnel using only IP-in-IP (example, IPv6/IPv4) 1239 * 0 1 0 0 0 1 -> Tunnel using UDP (example IPv6-UDP-IPv4) 1241 o USER_ID: The user login. It can be an ASCII text, coded or 1242 whatever. It is assigned during the registration process. To be 1243 further defined. 1245 o Random data: Data used to be included on the packet to prevent 1246 duplicate signatures. Either a random number, date, etc. To be 1247 further defined. 1249 o Signature: It is the field that actually authenticates the user. 1250 It is the result of ciphering with the private key the result of 1251 hashing the packet with a hash function (MD5, SHA1, ...). To be 1252 further defined. 1254 If no authentication is needed to request for extra-features on the 1255 tunnel, then USER_ID, Random and Signature fields are not required. 1257 9.2. ACK Packet 1259 This packet acknowledges the SI request and indicates the options 1260 that have been accepted. Also the SC can inform by means of this 1261 packet, about some parameters to the SI. The format is as follows: 1263 0 16 31 1264 +-----------------------------------+-----------------------------------+ 1265 | ID Length | Signature Length | 1266 +--------+-------------+------------------+-----+-----+--------+--------+ 1267 | Packet | Tunnel | Prefix |Keep.| NAT | Signat.| Encaps.| 1268 | Type | Type | Length |Peri.| Typ.| Type | Type | 1269 +--------+-------------+------------------+-----+-----+--------+--------+ 1270 | Prefix/IPv4 Address | 1271 +-----------------------------------------------------------------------+ 1272 | USER_ID | 1273 +-----------------------------------------------------------------------+ 1274 | Random | 1275 +-----------------------------------------------------------------------+ 1276 | Signature | 1277 +-----------------------------------------------------------------------+ 1279 Figure 14: ATS6 ACK packet 1281 o ID Length (16 bits): The length of the USER_ID field. 1283 o Signature Length (16 bits): The length of Signature field. 1285 o Packet Type (4 bits): Information about the packet type (ACK in 1286 this case). 1288 o Tunnel Type (5 bits): The tunnel type that has been accepted. 1289 Same meaning for the flags as above for the A&H packet. 1291 o Prefix Length (7 bits): If the SI request for a prefix delegation, 1292 indicates the desired prefix length. If the SC responds, 1293 indicates the delegated prefix length. 1295 o Keep-Alive Periodicity (3 bits): The periodicity defined by the SC 1296 for the keep-alive packets. Possible values as follows: 1298 * 000: One every minute 1300 * 001: One every 3 minutes 1302 * 010: One every 10 minutes 1304 * 011: One every 20 minutes 1306 * 100: One every 30 minutes 1308 * 101: One every 60 minutes 1310 * 110: One every 240 minutes 1312 * 111: No keep-alive packets are required at all 1314 * Note: It may be considered as convenient to random the keep- 1315 alive packets delivery, within the maximum periodicity 1316 indicated by this field, in order to statistically lower the 1317 simultaneous number of packets from the SIs to the SC (and SC 1318 to SIs), increasing the scalability of the system (do be 1319 further analyzed). 1321 o NAT Type (3 bits): The SC confirms to the SI if a NAT has been 1322 detected and the type: 1324 * 000 - no NAT or proto-41 compliant. 1326 * 001 - full-conned NAT. 1328 * 010 - symmetric NAT. 1330 * 011 - asymmetric NAT. 1332 * 1xx - Reserved for future use. 1334 o Signature Type (4 bits): The type of signature that has been 1335 accepted. 1337 o Encapsulation Type (6 bits): The type of encapsulation that has 1338 been accepted. Same meaning for the flags as above for the A&H 1339 packet. 1341 o Prefix/IPv4 address (64 bits): If the prefix or IPv4 address is 1342 provided by means of the ACK package, this field contains such 1343 parameter. The field is zero-left-padded. 1345 o USER_ID: The user login. It can be an ASCII text, coded or 1346 whatever. It is assigned during the registration process, and 1347 should match the one sent in the A&H packet. 1349 o Random data: Data used to be included on the packet to prevent 1350 duplicate signatures. Either a random number, date, etc. To be 1351 further defined. 1353 o Signature: It is the field that actually authenticates the user. 1354 It is the result of ciphering with the private key the result of 1355 hashing the packet with a hash function (MD5, SHA1, ...). To be 1356 further defined. 1358 If no authentication is needed to request for extra-features on the 1359 tunnel, then USER_ID, Random and Signature fields are not required. 1361 9.3. NO_ACK Packet 1363 This packet does not acknowledge the SI request and indicates the 1364 failure of the requested options. The format is as follows: 1366 0 16 31 1367 +-----------------------------------+-----------------------------------+ 1368 | ID Length | Signature Length | 1369 +--------+-------------+------------+-----------------+--------+--------+ 1370 | Packet | Tunnel | Reserved | Error | Signat.| Encaps.| 1371 | Type | Type | | Code | Type | Type | 1372 +--------+-------------+------------+-----------------+--------+--------+ 1373 | USER_ID | 1374 +-----------------------------------------------------------------------+ 1375 | Random | 1376 +-----------------------------------------------------------------------+ 1377 | Signature | 1378 +-----------------------------------------------------------------------+ 1380 Figure 15: ATS6 NO_ACK packet 1382 o ID Length (16 bits): The length of the USER_ID field. 1384 o Signature Length (16 bits): The length of Signature field. 1386 o Packet Type (4 bits): Information about the packet type (NO_ACK in 1387 this case). 1389 o Tunnel Type (6 bits): The tunnel type that has been requested. 1391 o Reserved (6 bits): Bits reserved for future use. 1393 o Error Code (8 bits): The reason of the "no acknowledgment". 1395 o Signature Type (4 bits): The type of signature requested by the 1396 SI. 1398 o Encapsulation Type (4 bits): The type of encapsulation requested 1399 by the SI. 1401 o USER_ID: The user login. It can be an ASCII text, coded or 1402 whatever. It is assigned during the registration process. 1404 o Random data: Data used to be included on the packet to prevent 1405 duplicate signatures. Either a random number, date, etc. To be 1406 further defined. 1408 o Signature: It is the field that actually authenticates the user. 1409 It is the result of ciphering with the private key the result of 1410 hashing the packet with a hash function (MD5, SHA1, ...). To be 1411 further defined. 1413 If no authentication is needed to request for extra-features on the 1414 tunnel, then USER_ID, Random and Signature fields are not required. 1416 10. Signaling Encapsulation 1418 It is important to note that at the time being, the signaling packets 1419 are chosen to be encapsulated as ICMPv6 ones (type to be 1420 standardized), assuming that the networks will tend to have, over the 1421 time, more native IPv6 support, so this will allow a more simpler 1422 support of IPv4-in-IPv6 encapsulation. Furthermore, using ICMPv6 1423 packets simplifies both the resources and the implementation of ATS6 1424 capable SCs and SIs. 1426 However, other choices are also possible, such as ICMPv6 packets 1427 encapsulated in UDP ones, UDP packets with the same format as the 1428 ICMPv6 here described, TCP, etc. The way how the signaling packets 1429 are encapsulated is not as important as the signaling itself. It 1430 will be also possible to support several of them, in order to ensure 1431 the success of the tunnel setup under any infrastructure conditions. 1433 The following are examples showing some of these alternatives: 1435 +-----------------------------------------------+ 1436 | SIGNALING PACKET | 1437 +-----------------------------------------------+ 1438 | ICMPv6 HEADER | 1439 | (to be defined) | 1440 +-----------------------------------------------+ 1441 | IP HEADER | 1442 +-----------------------------------------------+ 1444 Figure 16: ATS6 Signaling packets in ICMPv6 packets 1446 +-----------------------------------------------+ 1447 | SIGNALING PACKET | 1448 +-----------------------------------------------+ 1449 | ICMPv6 HEADER | 1450 | (to be defined) | 1451 +-----------------------------------------------+ 1452 | UDP HEADER | 1453 +-----------------------------------------------+ 1454 | IP HEADER | 1455 +-----------------------------------------------+ 1457 Figure 17: ATS6 Signaling packets in ICMPv6-UDP packets 1458 +-----------------------------------------------+ 1459 | SIGNALING PACKET | 1460 +-----------------------------------------------+ 1461 | UDP HEADER | 1462 +-----------------------------------------------+ 1463 | IP HEADER | 1464 +-----------------------------------------------+ 1466 Figure 18: ATS6 Signaling packets as payload of UDP packets 1468 11. Peer-to-Peer Optimization 1470 In case direct peer-to-peer among SIs is wanted, when they are 1471 connected in the same IPv4-only infrastructure, ATS6 provides a way 1472 to avoid all the encapsulated traffic being handled by the SC. 1474 An specific IPv6 prefix could be reserved for that purpose, so SIs 1475 would have one additional IPv6 address, which is built by appending 1476 to such prefix the same Interface Identifier used for the global IPv6 1477 address in the Basic Tunnel case described before. 1479 In this way, communication packets between peers do not need to be 1480 forwarded to the SC and then back to the peer, but instead, they can 1481 travel directly from one peer to the other one and vice-versa. 1483 Lots of resources (network, memory, CPU load, etc.) are saved at the 1484 SC by this means, in addition to the lower RTT, which improves the 1485 scalability of the protocol. 1487 Given the fact that SIs could be most probably behind a NAT box when 1488 trying to use this peer-to-peer optimization, all them will use UDP 1489 packets for building the tunnel, so in order to use the peer-to-peer 1490 optimization, the encapsulation should be IPv6-in-UDP-in-IPv4. It 1491 could be explored using the same prefix as Teredo [10] in order to 1492 allow also compatibility with that protocol and consequently allow 1493 peer-to-peer among Teredo [10] and ATS6 nodes. 1495 This optimization needs further detailed analysis. 1497 12. Security Considerations 1499 Threats on the tunnel data can be minimized by doing address-ingress 1500 filtering at the SC of both outer IPvX and inner IPvY protocols (i.e. 1501 in the IPv6-in-IPv4 tunnel case, the outer protocol is IPv6 and the 1502 inner one is IPv4). In this way spoofed address attacks are 1503 prevented not only for the inner address but also for the outer ones. 1505 If more security is required, the guidelines pointed by [13] to 1506 secure the tunnels should be followed. 1508 13. IANA Considerations 1510 TBD. 1512 14. Acknowledgements 1514 The author would like to acknowledge the inputs from ... 1516 15. References 1518 15.1. Normative References 1520 15.2. Informative References 1522 [1] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP", 1523 draft-nielsen-v6ops-3GPP-zeroconf-goals-00 (work in progress), 1524 October 2004. 1526 [2] Suryanarayanan, R., "Zero-Configuration Tunneling 1527 Requirements", draft-suryanarayanan-v6ops-zeroconf-reqs-00 1528 (work in progress), October 2004. 1530 [3] Parent, F., "Goals for Registered Assisted Tunneling", 1531 draft-ietf-v6ops-assisted-tunneling-requirements-01 (work in 1532 progress), October 2004. 1534 [4] Palet, J., "Goals for Tunneling Configuration", 1535 draft-palet-v6tc-goals-tunneling-00 (work in progress), 1536 February 2005. 1538 [5] Li, X., "Softwire Problem Statement", 1539 draft-ietf-softwire-problem-statement-00 (work in progress), 1540 December 2005. 1542 [6] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 1543 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 (work 1544 in progress), January 2005. 1546 [7] Palet, J., "IPv6 Tunnel End-point Automatic Discovery 1547 Mechanism", draft-palet-v6ops-solution-tun-auto-disc-01 (work 1548 in progress), October 2004. 1550 [8] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1551 - Simple Traversal of User Datagram Protocol (UDP) Through 1552 Network Address Translators (NATs)", RFC 3489, March 2003. 1554 [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1555 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1557 [10] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 1558 draft-huitema-v6ops-teredo-05 (work in progress), April 2005. 1560 [11] Palet, J., "Forwarding Protocol 41 in NAT Boxes", 1561 draft-palet-v6ops-proto41-nat-03 (work in progress), 1562 October 2003. 1564 [12] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration 1565 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 1567 [13] Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1568 draft-ietf-v6ops-ipsec-tunnels-01 (work in progress), 1569 August 2005. 1571 Authors' Addresses 1573 Jordi Palet Martinez 1574 Consulintel 1575 Molino de la Navata, 75 1576 La Navata - Galapagar - Madrid 1577 E-28420 - Spain 1579 Phone: +34 91 151 81 99 1580 Fax: +34 91 151 81 98 1581 Email: jordi.palet@consulintel.es 1583 Miguel Angel Diaz Fernandez 1584 Consulintel 1585 Molino de la Navata, 75 1586 La Navata - Galapagar - Madrid 1587 E-28420 - Spain 1589 Phone: +34 91 151 81 99 1590 Fax: +34 91 151 81 98 1591 Email: miguelangel.diaz@consulintel.es 1593 Intellectual Property Statement 1595 The IETF takes no position regarding the validity or scope of any 1596 Intellectual Property Rights or other rights that might be claimed to 1597 pertain to the implementation or use of the technology described in 1598 this document or the extent to which any license under such rights 1599 might or might not be available; nor does it represent that it has 1600 made any independent effort to identify any such rights. Information 1601 on the procedures with respect to rights in RFC documents can be 1602 found in BCP 78 and BCP 79. 1604 Copies of IPR disclosures made to the IETF Secretariat and any 1605 assurances of licenses to be made available, or the result of an 1606 attempt made to obtain a general license or permission for the use of 1607 such proprietary rights by implementers or users of this 1608 specification can be obtained from the IETF on-line IPR repository at 1609 http://www.ietf.org/ipr. 1611 The IETF invites any interested party to bring to its attention any 1612 copyrights, patents or patent applications, or other proprietary 1613 rights that may cover technology that may be required to implement 1614 this standard. Please address the information to the IETF at 1615 ietf-ipr@ietf.org. 1617 Disclaimer of Validity 1619 This document and the information contained herein are provided on an 1620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1622 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1623 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1624 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1625 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1627 Copyright Statement 1629 Copyright (C) The Internet Society (2006). This document is subject 1630 to the rights, licenses and restrictions contained in BCP 78, and 1631 except as set forth therein, the authors retain all their rights. 1633 Acknowledgment 1635 Funding for the RFC Editor function is currently provided by the 1636 Internet Society.