idnits 2.17.1 draft-vogt-rrg-six-one-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5296 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Christian Vogt 3 Internet-Draft Ericsson 4 Expires: April 29, 2010 October 26, 2009 6 Six/One: A Solution for Routing and Addressing in IPv6 7 draft-vogt-rrg-six-one-02 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may contain material 13 from IETF Documents or IETF Contributions published or made publicly 14 available before November 10, 2008. The person(s) controlling the 15 copyright in some of this material may not have granted the IETF 16 Trust the right to allow modifications of such material outside the 17 IETF Standards Process. Without obtaining an adequate license from 18 the person(s) controlling the copyright in such materials, this 19 document may not be modified outside the IETF Standards Process, and 20 derivative works of it may not be created outside the IETF Standards 21 Process, except to format it for publication as an RFC or to 22 translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 29, 2010. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 There is heightened concern about the growth of the global routing 56 table and the increased frequency of routing table updates. Both is 57 due to the use of provider-independent addressing space in edge 58 networks, which accommodates operators' desire to move traffic 59 quickly and easily from one provider to another. The main recent 60 proposals attempt to solve this problem by hiding provider- 61 independent addressing space through a level of indirection. 62 Unfortunately, indirection requires a non-trivial distribution of 63 address translation information across the Internet. This is either 64 slow, or costly in terms of signaling overhead, or both. Security 65 and transitionability are further issues. This document proposes an 66 alternative solution, which is based on a single, provider-dependent 67 addressing space and hence avoids the problems of indirection. The 68 solution meets the objectives of edge network operators while 69 limiting the size of the routing table and its update frequency. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 11 77 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 13 78 3.1. IP Address Configuration . . . . . . . . . . . . . . . . . 13 79 3.2. Source Address Selection . . . . . . . . . . . . . . . . . 13 80 3.3. Initiating a Session . . . . . . . . . . . . . . . . . . . 14 81 3.4. Protecting Address Bunches . . . . . . . . . . . . . . . . 16 82 3.5. Responding to a Session Initiation . . . . . . . . . . . . 18 83 3.6. Completing a Session Initiation . . . . . . . . . . . . . 19 84 3.7. Handling Outgoing Packets . . . . . . . . . . . . . . . . 20 85 3.8. Handling Incoming Packets . . . . . . . . . . . . . . . . 20 86 3.9. Network-Side Provider Selection and Address Rewriting . . 21 87 3.10. Session Shutdown . . . . . . . . . . . . . . . . . . . . . 22 89 4. Recommended Access Network Practices . . . . . . . . . . . . . 23 90 4.1. Subnet Prefix Assignment . . . . . . . . . . . . . . . . . 23 91 4.2. Router Configuration . . . . . . . . . . . . . . . . . . . 23 92 4.3. Host Configuration . . . . . . . . . . . . . . . . . . . . 24 93 4.4. Configuration of Traffic Control and Analysis Equipment . 25 95 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 5.1. Incentives for Deployment . . . . . . . . . . . . . . . . 28 97 5.2. Transition . . . . . . . . . . . . . . . . . . . . . . . . 29 98 5.3. Easing Universal Source Address Validation . . . . . . . . 30 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 104 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 33 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 107 9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 108 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 110 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in 116 [rfc2119-rfc-keywords]. 118 1. Introduction 120 The Internet traditionally consists of three classes of players: 121 users, edge network operators, and providers. Users operate hosts 122 for which they desire efficient, available, and reliable Internet 123 connectivity. Edge network operators provide the infrastructure that 124 hosts needs to communicate, collectively called the "edge domain". 125 An edge network can indepently route packets between two attached 126 hosts, but for global Internet connectivity, it must connect to a 127 provider. Providers jointly form a "transit domain" via which 128 packets can be exchanged between edge networks. 130 Edge network operators are naturally eager to meet the expectations 131 of users because they have a direct business relationship with the 132 users. An important tool edge network operators employ to accomplish 133 this is traffic engineering, which helps them to utilize available 134 edge network capacities in an optimum way. Edge network operators 135 further desire the ability to select providers in a dynamic manner 136 because the quality of a host's Internet connectivity depends on the 137 provider just as well as on the edge network. Technology should 138 permit flexible transition from one provider to another, so-called 139 "rehoming". Technology should also allow an edge network operator to 140 connect to multiple providers, so-called "multi-homing", and to 141 extend traffic engineering to dynamically reroute traffic between 142 those connections. 144 The crux with the new desire for flexible provider selection is that 145 the Internet was not designed to support it. For scalability 146 reasons, the preferred strategy for allocating Internet addressing 147 space is to hand out contiguous address blocks to providers, which in 148 turn delegate parts of their block to the edge networks they serve. 149 The address that a host uses to describe a point of Internet 150 attachment consequently identifies the provider via which the host is 151 reachable. The benefit of this is more efficient routing inside the 152 transit domain because the global "routing table", the routing state 153 that needs to be maintained and consulted on a per-packet basis, can 154 be limited to one entry per provider. The routes connecting transit 155 and edge domains can then be maintained locally by the respective 156 providers and the edge networks they serve. A smaller routing table 157 furthermore reduces the number of updates it is subject to. 159 On the other hand, provider-dependent addressing brings about grave 160 limitations for edge domain operators. An edge network operator that 161 wishes to rehome must reconfigure networking equipment for traffic 162 control and analysis as well as applications with preconfigured 163 addresses on hosts. This affects routers just as well as middleboxes 164 that store addresses, such as firewalls and intrusion detection 165 systems. Rehoming is therefore expensive and disruptive. A multi- 166 homed edge network is limited in its ability to pursue traffic 167 engineering because provider-dependent addresses effectively move the 168 priviledge of provider selection to the hosts: A host obtains an 169 address from each provider, and to ensure bidirectionality and 170 topological correctness, packets that the host sends must go via the 171 provider that is identified by the packet's source address. 173 A natural desire of edge network operators is therefore to gain 174 provider-independent addressing space. This would facilitate 175 rehoming without reconfiguration costs, as well as flexible provider 176 selection during multi-homing. The drawback of provider-independent 177 addressing space for edge networks is that it would require an entry 178 per edge network in the global routing table. The routing table size 179 would thus increase to a substantial extent and effectively slow down 180 the routing process. Moreover, the only way for an edge network to 181 select the provider through which it was to be reached would be an 182 update to its entry in the global routing table. This would take 183 effect slowly, and it would have the undesired consequence of more 184 frequent updates to the global routing table. 186 The conflict of interests between the transit domain and the edge 187 domain calls for a new approach to routing and addressing that 188 satisfies the following primary objectives: 190 1. Routing table size. The size of the global routing table must be 191 kept linear in the number of providers rather than linear in the 192 number of edge networks. 194 2. Routing table robustness. Traffic engineering in edge networks 195 or edge network rehoming must not require updates to the global 196 routing table. 198 3. Egress provider selection. A multi-homed edge network must be 199 able to select a provider for egress packets. Such selection 200 must take effect quickly. 202 4. Ingress provider selection. A multi-homed edge network must be 203 able to select a provider for ingress packets. The mechanism 204 that this requires for packet rerouting across the transit domain 205 must be responsive. 207 5. Rehoming. An edge network must be able to smoothly change the 208 set of providers it connects to, without incurring costly 209 reconfiguration of applications and networking equipment for 210 traffic control and analysis. 212 6. Transition. There must be a transition path for incremental 213 deployment of a routing and addressing solution, which allows 214 upgraded parts of the Internet to communicate with legacy parts. 216 Beside these primary objectives, there are a number of secondary 217 objectives. A routing and addressing solution that satisfies some or 218 all of these objectives would be of additional value for host, edge 219 network operators, or providers: 221 7. Host preferences. A host should have a means to suggest to the 222 edge network which provider it would prefer its packets to pass 223 through. 225 8. Routing performance. Traffic characteristics such as packet 226 propagation latencies, packet loss probabilities, or jitter 227 should not change. 229 9. Deployment incentives. Deployment of a routing and addressing 230 solution should yield direct benefits to those entities 231 investing in the deployment. 233 10. Integrability on hosts. A host-based routing and addressing 234 solution should be integrable with protocols for host mobility 235 and host multi-homing. 237 11. Integrability in the network. A network-based routing and 238 addressing solution should be integrable with source address 239 validation technology. 241 The main existing routing and addressing proposals are based on a 242 level of indirection between addressing space for use inside the edge 243 domain, and addressing space for efficient packet routing across the 244 transit domain. Two indirection functions perform forward and 245 reverse translations between edge domain addresses and transit domain 246 addresses. Specific proposals differ with respect to whether this 247 translation occurs through address rewriting or tunneling, and, more 248 importantly, with respect to where the indirection functions are 249 located. While one indirection function always borders the edge 250 network which address space is being translated, the other 251 indirection function may be located at the border of a remote edge 252 network, or inside the transit domain. A consequence of locating an 253 indirection function inside the transit domain is that edge network 254 addressing space must be provider-dependent. And to avoid a 255 dependency on a single provider, the edge network addressing space 256 should be shared as anycast addressing space by multiple providers, 257 each with its own indirection function. 259 The strength of indirection is that it requires special support only 260 in the form of indirection functions. It can thus be kept 261 transparent to hosts, and to the edge network except for the entity 262 providing an indirection function. Like provider-independent 263 addressing space in general, indirection thereby eliminates the 264 costly reconfiguration overhead that edge network rehoming normally 265 entails. It also allows a multi-homed edge network to select a 266 provider for egress packets and -- to the extent a remote indirection 267 functions can be altered quickly enough -- for ingress packets as 268 well. Indirection finally preserves the size of the global routing 269 table or the frequency by which this is updated. 271 A significant drawback of indirection is the need for a mechanism 272 that can distribute address translation information for an edge 273 network to indirection functions at other edge networks or inside the 274 transit domain. A suitable distribution mechanism needs to affect a 275 difficult trade-off between update latency and signaling overhead, 276 while still remaining responsive to urgent rerouting decisions of 277 edge network operators, such as for the purpose of provider fail- 278 over. A suitable distribution mechanism must also be robust to 279 impersonation and denial-of-service attacks. Both can be provided 280 through authentication. For scalability reasons, this is likely to 281 require public-key-based authentication, and hence notable processing 282 overhead and periodic inquiries about subverted and changed public 283 keys. 285 Indirection techniques that use provider-independent addressing space 286 inside the edge domain furthermore fail to provide a smooth 287 transition path. From the perspective of a correspondent host, the 288 address of a host behind an indirection function depends on whether 289 the edge network of the correspondent host already supports the 290 indirection. While it is feasible to modify DNS to tailor address 291 resolution to the resolving host, means of address resolution aside 292 from DNS, such as via SIP signaling or peer-to-peer protocols, might 293 not be fixable and become completely defunct 294 [nikander-ram-generix-proxying]. Another undesired consequence is 295 that, in case the edge network of the correspondent host is legacy, 296 but address resolution succeeds nonetheless, the indirection function 297 at the host would have to translate addresses also in the payloads of 298 the correspondent host's packets, thus behave as a classic network 299 address translator. 301 The routing and addressing solution proposed in this document, Six/ 302 One, avoids the problems of indirection by maintaining a single 303 addressing space of IPv6 addresses for both the edge domain and the 304 transit domain. Six/One borrows from Shim6 [ietf-shim6-proto] the 305 concept that multi-homed edge networks use provider-dependent 306 addressing space from each of their providers, and hosts use 307 addresses from all addressing spaces interchangeably without breaking 308 active communication sessions. The novel concept of Six/One is that 309 a host's addresses differ only in their high-order bits, which 310 enables an edge network or a provider to change the address in a 311 packet on the fly depending on the provider to with the packet is 312 routed. The address from which a host contacts a correspondent host 313 serves as a suggestion to the edge network which provider the host's 314 packets should be routed through. The edge network may follow this 315 suggestion, or rewrite the high-order bits of the address in 316 accordance with a provider of its own choice. Different than in 317 Shim6, edge networks thus retain the ability to select a particular 318 provider for ingress and egress packets. Hosts adapt to address 319 rewrites in that they modify subsequent packets accordingly before 320 injecting them into the network. Like other protocols that enable a 321 host to change its address during an active communication session -- 322 including, besides Shim6, also Mobile IPv6 and the Host Identitity 323 Protocol --, Six/One adds to packets a small piece of information 324 that enables the receiving hosts to reverse address rewrites. The 325 novel concept in Six/One is that this information can also be used 326 inside an edge network to identify a remote host despite address 327 changes. Moreover, the high-order bits in addresses from local 328 addressing space can be masked when stored in applications or 329 networking equipment for traffic control and analysis, so as to spare 330 costly reconfiguration overhead in the event of rehoming. This 331 resembles the concept of 8+8 [odell-8+8], with the main difference 332 that hosts remain to be aware of their full addresses, including the 333 high-order bits, and that they can suggest to the edge network a 334 provider for their packets as explained above. 336 Through the use of provider-dependent addressing space in both the 337 edge domain and the transit domain, Six/One preserves both the size 338 of the global routing table as well as the frequency at which the 339 routing table is updated. For the same reason, Six/One precludes 340 degradations in routing performance. A three-phase transition path 341 will smoothly lead towards a universal deployment of Six/One. 342 Deployment will be accelerated by the right incentives, since even 343 partial deployment will provide advantages for the pioneers. The 344 host support that is needed for Six/One integrates well with host 345 mobility and host multi-homing procotols. The required network 346 support facilitates source address validation at no extra costs for 347 the edge network operator or provider. In summary, Six/One satisfies 348 all of the aforementioned primary and secondary objectives. 350 2. Conceptual Overview 352 This section gives a conceptual overview of the Six/One protocol, and 353 it provides rationale for the design decisions made. 355 The refrainment from introducing separate addressing spaces for the 356 edge domain and the transit domain implies that the IPv6 addressing 357 architecture (RFC 4291) and the preferred policy of allocating 358 provider-dependent addressing space to edge networks remain as is. 359 From a host's perspective, an IPv6 address is still split into a 64- 360 bit "subnet prefix" and a 64-bit "interface identifier", as shown in 361 Figure 1. A subnet prefix is advertised by an access router, and the 362 host extends this with an interface identifier to form a full 363 address. From an edge network's perspective, a subnet prefix can 364 further be decomposed into a "routing prefix", which identifies the 365 provider from which the addressing space was obtained, and a "subnet 366 ID", which is used by the edge network to identify internal links. 367 The length of the routing prefix determines the size of the 368 addressing space, which is up to the contract between the edge 369 network and the provider. The length of the subnet ID is such that, 370 together with the routing prefix, it adds up to 64 bit. 372 |<----------- 64 bit ----------->|<----------- 64 bit ----------->| 374 +--------------------------------+--------------------------------+ 375 | subnet prefix | interface identifier | 376 +--------------------------------+--------------------------------+ 378 | routing prefix | subnet ID | 380 Figure 1: IPv6 address structure 382 What Six/One adds to IPv6 is an ability for hosts to configure sets 383 of addresses, so-called "address bunches", that differ only in the 384 routing prefixes, and to use these addresses interchangeably without 385 breaking active communication sessions. An instance of Six/One at 386 the host's IPv6 layer ensures that switches between addresses from 387 the same bunch are kept transparent to protocols above. 389 The concept of address bunches enables a host sending a packet, or a 390 router on the packet's path, to change the routing prefix in an 391 address of the packet without destroying the relationship between the 392 address and the host to which it belongs. (A host generally does not 393 know the length of a routing prefix, so technically, it rewrites an 394 entire 64-bit subnet prefix. But since all addresses in a bunch have 395 the same subnet ID, only the routing prefix can change during this 396 operation.) As the routing prefixes in the addresses of a packet 397 define the providers through which the packet enters or leaves the 398 transit domain, routing prefix rewriting can force the packet to go 399 via a different provider pair than the one corresponding to the 400 original addresses. The correspondent host receiving the packet 401 recognizes and reverses routing prefix rewrites so that packets are 402 handed to protocols above Six/One as they were generated initially. 403 The correspondent host further memorizes a routing prefix rewrite and 404 adapts in that it directly rewrites the addresses in packets that it 405 generates itself before injecting the packets into the network. This 406 not only relieves the network from the burden of continued routing 407 prefix rewriting, it also ensures that packets exchanged in either 408 direction pass the same pair of providers. The result is a quick, 409 bidirectional adoption of a new provider, which is essential in 410 particular during provider fail-over. 412 To support the new interchangeability of addresses, a host must be 413 aware of its own address bunch as well as of the address bunch of the 414 "correspondent host" it communicates with. The host must further 415 remember which address from each bunch it is to use at protocols 416 above Six/One. The host maintains all of this information as a per- 417 communication-session "context". A context is securely created on 418 both sides of a connection during session establishment. Each 419 context is assigned a "context identifier", which is carried in all 420 packets of the session to aid the retrieval of the right context at 421 the receiving host. 423 Six/One itself handles edge network multi-homing, but it is not a 424 solution for host mobility, host multi-homing, or host identity 425 management. These latter challenges must be addressed by a separate 426 protocol such as Mobile IPv6 or the Host Identity Protocol. However, 427 it is possible to integrate Six/One with host mobility, host multi- 428 homing, or host identity protocols so as to reduce network protocol 429 stack complexity and signaling overhead. For example, all of these 430 protocols include information for context retrieval in packets, such 431 as a Six/One context identifier, a Mobile IPv6 home address, or an 432 IPsec security parameter index in the case of the Host Identity 433 Protocol. This information could be shared amongst the protocols. 434 The new paradigm of address bunches and address rewriting in routers 435 may furthermore be incorporated into future-Internet architectures. 436 One example is the Node ID architecture [schuetz-nid-arch], which 437 builds on the Host Identity Protocol and augments the Internet by a 438 mechanism for identity-based overlay routing to help hosts discover 439 their mutual IP addresses. 441 3. Protocol Operation 443 This section describes the operation of Six/One in detail. 445 3.1. IP Address Configuration 447 To allow the routing prefix of an address to be rewritten without 448 changing the address owner, addresses must be configured in bunches. 449 This may happen through manual preconfiguration, or through stateless 450 or stateful auto-configuration. A host that uses stateless address 451 auto-configuration can configure an address bunch through successive 452 execution of the protocol for each address in the bunch. In the 453 unlikely event of a collision, the host discards the incomplete 454 address bunch and tries anew with a different interface identifier. 456 The signaling overhead in the above application of stateless address 457 auto-configuration does not differ from the standard use if no 458 collision occurs, or if a collision occurs already during the 459 configuration of the first address in the bunch. Some extra 460 signaling overhead is spent in case a collision occurs after the 461 first address has been configured because every previous address 462 configuration was then in vain. However, if all neighbor hosts on 463 the same link use address bunches as well, a collision can only occur 464 during the configuration of the first address in a bunch. 466 [To be done: Stateful address auto-configuration with DHCPv6.] 468 Six/One ensures that routing prefix rewrites are transparent to 469 protocols above Six/One, so that they do not cause communication 470 sessions to abort. In the following it will be assumed that the host 471 configures a single address bunch. This assumption goes without loss 472 of generality. 474 3.2. Source Address Selection 476 All addresses in a bunch are visible to protocols above Six/One, and 477 all may be advertised in DNS. An application may select any of these 478 addresses as a local address for a new communication session, and any 479 address that DNS advertises for the correspondent host may be used as 480 a remote address. The local and remote addresses used by protocols 481 above Six/One are called "primary addresses". Primary addresses 482 never change throughout a communication session. The local and 483 remote addresses into which Six/One translates a packet's source and 484 destination addresses are called "active addresses". Figure 2 485 illustrates which values a packet's source and destination addresses 486 take before and after processing by Six/One. 488 +----------------------------------------------+ 489 | source address = primary local address | 490 | destination address = primary remote address | 491 | | 492 : : 493 /\ | | 494 / \ | | 495 | | Six/One | | 496 | | \ / 497 | | \/ 499 +----------------------------------------------+ 500 | source address = active local address | 501 | destination address = active remote address | 502 | | 503 : : 505 Figure 2: Packet addresses before and after Six/One processing 507 A host is in general agnostic with respect to the topological meaning 508 of a subnet prefix, and it simply considers the subnet prefix an 509 opaque 64-bit value. The host then selects a source address for a 510 new communication session without preference. However, if a host is 511 able to map routing prefixes onto the corresponding providers, the 512 host can express a preference for a particular provider by picking a 513 source address with that provider's routing prefix. Unless the 514 suggestion gets overwritten by the edge network, this allows the host 515 to have its packets routed via a provider of its own choice. 517 3.3. Initiating a Session 519 To be able to pursue, verify, and reverse routing prefix rewrites in 520 the addresses of ingress and egress packets, a host must be aware of 521 the local and remote addresses that are legitimate for a particular 522 communication session as well as which of these addresses are 523 primary. The host maintains this information in "contexts". The 524 "local context" for a communication session comprises the primary 525 local address used in the session, the address bunch from which the 526 primary local address was taken, and a context ID that is unique for 527 all local contexts of the host. The host further maintains a "remote 528 context" for each communication session, which equals the local 529 context of the respective correspondent host. The remote context is 530 retrieved during session establishment. A remote context is 531 identified by the combination of the context ID chosen by the 532 correspondent host, and any address in the correspondent host's 533 address bunch. 535 A host that wishes to initiate a communication session with a 536 correspondent host first allocates a local context based on the 537 primary local and remote addresses chosen by the application as well 538 as the address bunch to which the local address belongs. The host 539 assigns the local context a context ID that has not been assigned to 540 another local contexts. In case the host already has a local context 541 for the same primary local and remote addresses, then this may be 542 reused for the new communication session. The local context is 543 finally bound to the session in an implementation-specific manner. 545 The host further allocates a remote context for the communication 546 session. If a remote context already exists for the same primary 547 local and remote addresses, then it may be reused for the new 548 communication session. Otherwise, the host creates a preliminary 549 remote context at this stage, which contains only the primary local 550 and remote addresses. The missing parts of the remote context will 551 be retrieved subsequently during session establishment. The remote 552 context, too, is bound to the session in an implementation-specific 553 manner. 555 Figure 3 shows an example of the host's local and preliminary remote 556 contexts at the time the correspondent host is contacted. The host 557 has elected to use the local address RP1a:SID1::IID1 as a primary 558 local address in the communication session, where "RP1a" denotes the 559 routing prefix, "SID1" the subnet ID, and "IID1" the interface 560 identifier. The host's address bunch also contains a second address 561 with routing prefix "RP1b". The correspondent host's address RP2a: 562 SID2::IID2 is used as the primary address in the preliminary remote 563 context, where the routing prefix, subnet ID, and interface 564 identifier are "RP2a", "SID2", and "IID2", respectively. The context 565 ID of the host's local context is CID1, whereas the context ID of the 566 remote context is yet unknown. 568 host | local context | remote context 569 ------------------+------------------+----------------- 570 context ID | CID1 | (unknown) 571 | | 572 primary address | RP1a:SID1:IID1 | RP2a:SID2:IID2 573 active address | RP1a:SID1:IID1 | RP2a:SID2:IID2 574 | | 575 address bunch | RP1a:SID1:IID1 | RP2a:SID2:IID2 576 | RP1b:SID1:IID1 | (rest unknown) 578 Figure 3: Host's contexts on session establishment 580 The primary local and remote addresses are used as the source and 581 destination addresses, respectively, in the first packet that the 582 host sends to the correspondent host. This first packet carries an 583 IPv6 Destination Options extension header with a new "Context Setup 584 option" that includes the parameters of the host's local context. 586 3.4. Protecting Address Bunches 588 The ability to send and receive packets via an active address that 589 differs from the primary address visible for protocols above Six/One 590 must be protected against misuse. Failure to provide appropriate 591 security measures would enable a malicious host to communicate with a 592 correspondent host on behalf of a victim host. Such an 593 "impersonation attack" calls for the malicious host to register with 594 the correspondent host an address bunch that includes the victim 595 host's address as primary, and an address at which the malicious node 596 itself is reachable as active. The malicious host could then 597 exchange packets with the correspondent host via the active address, 598 whereas protocols above Six/One on the correspondent host would see 599 the primary address and hence assume to be communicating with the 600 victim host. The interface identifier of the active address would 601 have to be the same as that of the primary, that is, the victim 602 host's address. But a malicious host can easily configure an 603 appropriate active address if the malicious host resides on an access 604 link that permits stateless address auto-configuration. Even with 605 other address configuration means, it may still be possible for the 606 malicious host to send packets from a spoofed address with the 607 desired interface identifier, and to overhear packets delivered to 608 that same address. 610 To prevent impersonation attacks, Six/One requires a host to prove to 611 its correspondent host that it is the legitimate owner of its primary 612 address. This address ownership proof is provided through a 613 cryptographic binding between the subnet prefixes of the addresses in 614 the host's bunch and the common interface identifier of these 615 addresses. The host creates the cryptographic binding when it 616 generates an address bunch, and the correspondent host verifies the 617 binding during context establishment. This makes it infeasible for a 618 malicious host to create an address bunch that contains both a victim 619 host's address and an address at which it is reachable itself. 621 The technique Six/One uses to create the cryptographic binding 622 between the different subnet prefixes and the common interface 623 identifier in an address bunch is based on the generation and 624 verification algorithms for Cryptographically Generated Addresses 625 [rfc3972-cga] and Hash-Based Addresses [ietf-shim6-hba]. The 626 technique differs, however, in that it yields a single interface 627 identifier for all addresses in a bunch, although these addresses 628 have different subnet prefixes. A host generates an address bunch 629 according to Section 6 in [ietf-shim6-hba] with the exception of 630 steps 6.1 and 6.5, which are modified such that the CGA parameters no 631 longer emphasize a particular subnet prefix: 633 6.1. Concatenate from left to right the final Modifier value, 64 634 zero bits, the collision count, the encoded public key or the 635 encoded Extended Modifier (if no public key was provided) and 636 the Multi-Prefix extension. Execute the SHA-1 algorithm on the 637 concatenation. Take the 64 leftmost bits of the SHA-1 hash 638 value. The result is Hash1[i]. 640 6.5. Form the CGA Parameters data structure that corresponds to 641 HBA[i] by concatenating from left to right the final modifier 642 value, Prefix[i], the final collision count value, the encoded 643 public key or the encoded Extended Modifier and the Multi- 644 Prefix extension. 646 Six/One further requires a correspondent host to verify the 647 cryptographic binding between the different subnet prefixes and the 648 common interface identifier in an address bunch according to Section 649 7 in [ietf-shim6-hba] with the exceptions that step 2.2 is omitted, 650 and that step 1 is modified to no longer emphasize a particular 651 subnet prefix: 653 1. Verify that the 64-bit HBA prefix is included in the prefix set 654 of the Multi-Prefix extension. If it is not included, the 655 verification fails. Otherwise, fill the Subnet Prefix field of 656 the CGA Parameter data structure with 64 zero bits. 658 It should be emphasized that, although the above modifications 659 effectively eliminate the Subnet Prefix field in a CGA Parameters 660 data structure, the Multi-Prefix extension of the data structure 661 still lists the set of subnet prefixes of an address bunch. This 662 upholds the cryptographic binding between the subnet prefix and the 663 interface identifier for each address in the bunch. 665 The described cryptographic binding between the subnet prefixes and 666 the interface identifier in an address bunch is the default address 667 ownership proof if Six/One is used without a host mobility, host 668 multi-homing, or host identity protocol, such as Mobile IPv6 or the 669 Host Identity Protocol. However, if Six/One is combined with one of 670 these protocols, that protocol effectively provides the primary 671 address, and the address ownership proof performed by that protocol 672 can replace the default address ownership proof of Six/One. For 673 example, if Six/One is combined with the Host Identity Protocol, a 674 host's primary address becomes a host identity tag, and the proof of 675 ownership of the host identity tag is accomplished through IPsec- 676 based authentication. 678 3.5. Responding to a Session Initiation 680 When a correspondent host receives from a host a packet that includes 681 an IPv6 Destination Options extension header with a Context Setup 682 option, the correspondent host allocates a remote context for the 683 host based on the parameters in the Context Setup option. This may 684 be a new context or a reused one. The active local and remote 685 addresses in the context are set to the source and destination 686 addresses in the received packet. Since the subnet prefixes of the 687 addresses in this first packet may already have been rewritten -- 688 either by Six/One on the host prior to packet transmission, or later 689 on in the network --, the active local and remote addresses may 690 differ from the corresponding primary addresses. 692 The correspondent host further allocates a local context for the 693 communication session based on the address bunch that includes the 694 destination address of the incoming packet. The local context may 695 again be new or reused, and it uses the same active addresses as the 696 remote context for this session. 698 Figure 4 continues the example of Figure 3 with an illustration of 699 the contexts that the correspondent host has at this point. The 700 figures differ in that the roles of the local and remote contexts are 701 reversed, and in that both contexts are now complete. The 702 correspondent host's local context has context ID "CID2". And 703 besides the primary address RP2a:SID2:IID2, its address bunch 704 includes two more addresses, RP2b:SID2:IID2 and RP2c:SID2:IID2, where 705 "RP2b" and "RP2c" are additional routing prefixes. In this example, 706 the routing prefix of the packet's source address was rewritten in 707 the network because the active address in the correspondent host's 708 remote context is RP1b:SID1:IID1, whereas the active address on the 709 host's local context used to be RP1a:SID1:IID1 at the time the packet 710 was sent. 712 correspondent host | local context | remote context 713 ---------------------+------------------+----------------- 714 context ID | CID2 | CID1 715 | | 716 primary address | RP2a:SID2:IID2 | RP1a:SID1:IID1 717 active address | RP2a:SID2:IID2 | RP1b:SID1:IID1 718 | | 719 address bunch | RP2a:SID2:IID2 | RP1a:SID1:IID1 720 | RP2b:SID2:IID2 | RP1b:SID1:IID1 721 | RP2c:SID2:IID2 | 723 Figure 4: Correspondent host's contexts on session establishment 725 The correspondent host typically returns a packet to the host as a 726 response to the packet received. This packet is used to communicate 727 the parameters of the peer's local context back to the host, again 728 with a Context Setup option in an IPv6 Destination Options extension 729 header. 731 3.6. Completing a Session Initiation 733 The host completes the preliminary remote context for the 734 correspondent host when it receives the first packet from the 735 correspondent host that includes an IPv6 Destination Options 736 extension header with a Context Setup option. Both the host and the 737 correspondent host have then complete local and remote contexts for 738 the communication session. As with all subsequent packets received 739 from the correspondent host, the host also resets the active 740 addresses in its local and remote contexts to the received packet's 741 destination and source addresses, respectively, so as to adapt to any 742 address rewrites. 744 Figure 5 illustrates the local and remote contexts at the host at 745 this point, concluding the example from the previous figures. Since 746 the correspondent host has sent the packet to the active address in 747 its remote context, which is RP1b:SID1:IID1, the host has changed the 748 active address in its local context to RP1b:SID1:IID1 accordingly. 750 host | local context | remote context 751 ------------------+------------------+----------------- 752 context ID | CID1 | CID2 753 | | 754 primary address | RP1a:SID1:IID1 | RP2a:SID2:IID2 755 active address | RP1b:SID1:IID1 | RP2a:SID2:IID2 756 | | 757 address bunch | RP1a:SID1:IID1 | RP2a:SID2:IID2 758 | RP1b:SID1:IID1 | RP2b:SID2:IID2 759 | | RP2c:SID2:IID2 761 Figure 5: Host's contexts for established session 763 3.7. Handling Outgoing Packets 765 When a host has a packet to send that was delivered by a protocol 766 above Six/One, the host may have to rewrite the routing prefixes of 767 the packet's source and destination addresses so as to direct the 768 packet via a provider that was recently chosen by the network. The 769 host must further include sufficient information in the packet to 770 enable the correspondent host to reverse these address changes before 771 handing the packet to protocols above Six/One at the receiving side. 773 The source and destination addresses that the host is supposed to use 774 when sending a packet are, respectively, recorded in the active 775 addresses of the local and remote contexts of the communication 776 session. As delivered by the protocol above Six/One, the source 777 address in the packet contains the primary local address. The host 778 replaces this with the active address from the local context. 779 Moreover, the packet's destination address contains the primary 780 remote address when the packet is received from the protocol above 781 Six/One. This is replaced with the active address from the remote 782 context. 784 To enable the correspondent host to map the packet onto the correct 785 local and remote contexts, all packets except the first in a new 786 communication session are endowed with the sending host's local and 787 remote context IDs for the session. This information is carried in a 788 "Context ID option" of an IPv6 Destination Options extension header. 790 3.8. Handling Incoming Packets 792 A correspondent host that receives a packet from the network uses the 793 Context ID option in the packet's IPv6 Destination Options extension 794 header to retrieve the correct local and remote contexts. The local 795 context is obtained based on only the local context ID given in the 796 option. It is used to replace the destination address in the 797 received packet with the primary local address. The remote context 798 is obtained based on the combination of the remote context ID given 799 in the option and the packet's source address. It is used to replace 800 the packet's source address with the primary remote address. 802 The correspondent host must further memorize which source and 803 destination addresses the packet arrived with, so that the same local 804 and remote addresses can be used for packets that it sends 805 subsequently in the same communication session. This is accomplished 806 by resetting the active addresses in the local and remote contexts to 807 the packet's destination address and source address, respectively. 809 3.9. Network-Side Provider Selection and Address Rewriting 811 It is up to the edge network to decide via which provider an egress 812 packet shall be routed. One possibility is for the edge network to 813 accept the provider that is indicated by the routing prefix of the 814 egress packet's source address. The provider is then effectively 815 selected by the host sending the packet. On the other hand, traffic 816 engineering strategies or other local policies may require the edge 817 network to route packets via a different provider than implied by 818 their source addresses. The edge network can then preempt the 819 provider selection of a sending host. 821 In case an egress packet is routed via a different provider than the 822 one implied by the packet's source address, the subnet prefix of the 823 source address must be rewritten to one with a routing prefix from 824 the provider chosen by the edge network. Besides ensuring 825 topological correctness, this makes egress and ingress packets of a 826 particular communication session go via the same provider, which is 827 important to support efficient provider fail-over. Network-side 828 address rewrites do not effect a packet's destination address, nor 829 any addresses that appear outside the packet's IPv6 header. Like 830 address rewrites that are pursued by Six/One on a sending host, 831 network-side address rewrites are reversed by Six/One on the 832 receiving host. 834 Without loss of generality, it can be assumed that provider selection 835 and address rewrites be accomplished by routers. Both can happen 836 anywhere in the edge network, like directly on a first-hop router, 837 somewhere inside the edge network, or at the border to the edge 838 network's providers. Address rewriting may furthermore be delegated 839 to a provider. 841 In rewriting the subnet prefix of an address, a router must ensure 842 that the old and the new address belong to the same host. The router 843 must hence in general know the set of subnet prefixes that are valid 844 on the link from which a packet originates. This requirement can be 845 eliminated through a wise assignment of subnet prefixes to individual 846 links, as described in Section 4.1 and Section 4.2. 848 3.10. Session Shutdown 850 Contexts are soft-state and do not explicitly need to be revoked. 851 Hosts keep both remote and local contexts as long as there are 852 protocols above Six/One that use these contexts. A context is kept 853 for a while also after all protocols above Six/One have stopped using 854 it since the context might be picked up by a new communciation 855 session shortly thereafter. Contexts are finally disposed after a 856 predefined idle time, where the idle time for local contexts should 857 be a bit longer than the idle time for remote contexts. A remote 858 context reused by a host is therefore very likely to still exist as a 859 local context at the correspondent host even after a communication 860 pause. 862 4. Recommended Access Network Practices 864 Since hosts configure and select addresses without considering the 865 structure of a subnet prefix, edge network operators have the freedom 866 to constuct subnet prefixes in arbitrary manner. On the other hand, 867 a clean separation between routing prefixes and subnet IDs can reduce 868 the cost of edge network rehoming substantially, as explained in this 869 section. 871 4.1. Subnet Prefix Assignment 873 The recommended practice for assigning subnet prefixes to links in an 874 edge network is to give each link a single subnet ID that is unique 875 across the edge network. A link's subnet ID is combined with a each 876 of the edge network's routing prefixes to form the set of subnet 877 prefixes for the link. Within the scope of the edge network, a link 878 can then be identified based on its subnet ID alone, and the routing 879 prefix attached to the subnet ID does not have to be considered. 881 4.2. Router Configuration 883 For a router to inform hosts and other routers about the subnet 884 prefixes that are valid on a link it attaches to, the router must 885 learn these subnet prefixes up front. Nowadays, routers are 886 typically configured with entire subnet prefixes. This practice 887 requires costly reconfiguration of subnet prefixes in each individual 888 router when the edge network rehomes. The reconfiguration overhead 889 can be reduced substantially if edge network operators follow the 890 recommended practice for subnet prefix assignment described in 891 Section 4.1, and configure routers with the subnet ID of each link 892 they attach to and, separately, a list of the routing prefixes shared 893 by all links in the edge network. A router then builds the set of 894 subnet prefixes for a link automatically by concatenating each of the 895 routing prefixes with the subnet ID for this link. 897 In the event of edge network rehoming, the list of routing prefixes 898 gets updated, but the subnet ID of each link remains unchanged. It 899 is then sufficient to distribute a new list of routing prefixes 900 across all routers in the edge network. Since this list is the same 901 for all links in the edge network, router reconfiguration becomes 902 simpler than it would be if entire subnet prefixes were to be 903 replaced. Once a router has automatically reconstructed the subnet 904 prefixes of a link that it attaches to, it starts advertising the new 905 subnet prefixes to hosts on the link, and announces them via the 906 edge-network-internal routing protocol. This causes hosts to 907 automatically reconfigure their network protocol stacks and updates 908 the routing table in other routers. 910 The reconfiguration process during rehoming can be further simplified 911 by using only the link-local subnet prefix, or unique local 912 [rfc4193-unique-local-ip6] subnet prefixes on links to which no hosts 913 attach. These subnet prefixes include provider-independent routing 914 prefixes that do not change during edge network rehoming. 916 The recommended subnet prefix assignment practice also reduces the 917 cost of configuration and rehoming-related reconfiguration of routers 918 that are responsible for rewriting the addresses in packets. These 919 routers must generally know the set of subnet prefixes that are valid 920 on the link from which a packet was sent, so as to ensure that a 921 rewritten address belongs to the same address bunch (and hence to the 922 same host) as the original address. Replacing the routing prefix 923 alone may in general not be sufficient since subnet prefixes of the 924 same link may differ also in their subnet IDs. (The IPv6 addressing 925 architecture [rfc4191-ip6-architecture] leaves edge network operators 926 the freedom to assign subnet prefixes of arbitrary structure to their 927 links.) On the other hand, if edge network operators follow the 928 recommended subnet prefix assignment practice, all subnet prefixes on 929 a link use the same subnet ID. Address rewriting then does affect 930 only a routing prefix, and it can be accomplished without knowledge 931 of the subnet prefixes in use on the link from which a packet 932 originates. 934 4.3. Host Configuration 936 It is in some cases desired to manually preconfigure a host with an 937 address for itself or for certain correspondent hosts. As an 938 example, a simple application might hard-code the address of a server 939 that it needs to contact, or a network management script may included 940 hard-coded addresses for test or debugging purposes. Such address 941 preconfiguration increases the costs of edge network rehoming because 942 each of the preconfigured addresses must then be changed. This is 943 oftentimes a cumbersome manual process. 945 With Six/One, host reconfiguration due to rehoming can be eliminated 946 by using unique local addresses for address preconfiguration. Unique 947 local addresses have a randomized, provider-independent routing 948 prefix that the edge network operator chooses autonomously. Hosts in 949 the same edge network can use unique local addresses -- as both 950 source and destination addresses -- to communicate with each other. 951 Applications on the host can furthermore use the unique local address 952 as a primary local address when communicating with a correspondent 953 host in a different edge network. The unique local address then 954 always gets rewritten to an address in the host's address bunch, 955 which the host has automatically configured based on the subnet 956 prefixes of the link it attaches to. To enable the correspondent 957 host to verify that the unique local address and the address bunch 958 belong together, the preconfigured address can be included in the 959 computation of the interface identifier. 961 By definition, two hosts in the same edge network never use the same 962 unique local address. Chances that the unique local addresses of 963 hosts in different edge networks collide are negligible given the 964 randomized selection of routing prefixes for these addresses. 966 It would theoretically be possible to preconfigure a host also with 967 the unique local address of a correspondent host in a different edge 968 network. The unique local subnet prefix of the other edge network 969 would then have to be known in the host's edge network, and a router 970 on the path of the host's packets would have to rewrite the 971 correspondent host's unique local address to an address with the 972 other edge network's provider-dependent routing prefixes. However, 973 for simplicity, it is recommended here that hosts obtain the 974 addresses of correspondent hosts in other edge networks through DNS. 976 4.4. Configuration of Traffic Control and Analysis Equipment 978 Networking equipment for traffic control and analysis, such as a 979 firewall or an intrusion detection system, generally uses the 980 addresses in intercepted packets to identify the sending and 981 receiving hosts. This is based on the assumption that a host's 982 address remains stable throughout the duration of a communication 983 session. For the networking equipment to function correctly in the 984 presence of Six/One, hosts must be identified in a way that allows 985 the subnet prefixes in a host's address to change during a session. 987 Unique identification of hosts that reside in the same edge network 988 as the piece of networking equipment under consideration is 989 straightforward if edge network operators follow the recommended 990 practice for subnet prefix assignment described in Section 4.1. All 991 subnet prefixes of a particular link then have the same subnet ID, 992 and the addresses in a host's address bunch differ only in their 993 routing prefixes. Networking equipment can thus uniquely identify a 994 host in the local edge network based on only the subnet ID and the 995 interface identifier of the host's addresses. 997 In practice, networking equipment may be preconfigured with a 998 "routing mask", indicating the common length of the routing prefixes 999 that the edge network has obtained from its different providers. 1000 Assuming the routing prefix length is L, the routing mask can be 1001 thought of as a string of 128 bits of which the first L bits are "1" 1002 and the last 128-L bits are "0". A bit-wise And operation between a 1003 host's address and the inverted routing mask then yields a bit string 1004 that uniquely identifies the host across Six/One-related address 1005 changes. 1007 Since networking equipment in one edge network has in general no 1008 knowledge on the structure of subnet prefixes used in remote edge 1009 networks, it must identify correspondent hosts in remote edge 1010 networks differently than hosts in the local edge network. Even if 1011 the operator of a remote edge network also followed the subnet prefix 1012 assignment practice described in Section 4.1, there could still be a 1013 link in a third edge network with the same subnet ID and a different 1014 routing prefix. Networking equipment could hence confuse 1015 correspondent hosts in different remote edge networks if it 1016 identified those correspondent hosts based on only their subnet IDs 1017 and interface identifiers. On the other hand, since a host in the 1018 local edge network selects a separate context identifier for each 1019 correspondent host it communicates with, a correspondent host can be 1020 uniquely identified based on this context identifier in combination 1021 with the subnet ID and interface identifier in the address of the 1022 host in the local edge network. 1024 Figure 6 illustrates the operation of a firewall that identifies 1025 hosts as described above. The figure shows an edge network that 1026 multi-homes with two providers. Based on an estimated need to 1027 address hosts on up to 2^16 links, the edge network operator has 1028 requested one 48-bit routing prefix from each provider. Provider P1 1029 has assigned routing prefix PP1::/48 to the edge network, and 1030 provider P2 has assigned PP2::/48. Accordingly, the edge network's 1031 routing mask amounts to FF:FF:FF:FF:FF:FF::/48. The remaining 16 1032 bits inside 64-bit subnet prefixes are then used to form subnet IDs. 1033 The single link visible in Figure 6 is assigned subnet ID SID. This 1034 in combination with the two routing prefixes obtained by the edge 1035 network yields two subnet prefixes, PP1:SID::/64 and PP2:SID::/64, 1036 that are to be advertised by the router shown in the figure. 1037 Figure 6 furthermore shows two hosts, X and Y, that attach to the 1038 same link as the router. The interface identifiers that the hosts 1039 use to configure address bunches are IIDx and IIDy, respectively. 1040 Since the interface identifier is the same for all addresses in a 1041 bunch, and so is the subnet ID, hosts X and Y can be identified by 1042 the address postfixes ::SID:IIDx and ::SID:IIDy, respectively. This 1043 is exactly what the firewall inside the edge network does for host X, 1044 which at that point is communicating with correspondent host Z. The 1045 firewall furthermore identifies correspondent host Z based on the 1046 context identifier CIDx, which host X uses for the communication 1047 session with host Z, and host X's address postfix ::SID:IIDx. The 1048 firewall hence continues to function correctly when Six/One causes 1049 either of the hosts to switch to a different address in its 1050 respective bunch. There is also no need to reconfigure the firewall 1051 when the edge network rehomes. 1053 +------------------+ 1054 | | 1055 | host Z | 1056 | | 1057 +------------------+ 1058 | 1059 _________________________________________________|___________ 1060 ( ) 1061 ( ) 1062 ( Internet core ) 1063 ( ) 1064 (_____________________________________________________________) 1065 | | 1066 ____________|____________ ____________|____________ 1067 ( ) ( ) 1068 ( ISP P1 assigns ) ( ISP P2 assigns ) 1069 ( IP address block PP1::/48 ) ( IP address block PP2::/48 ) 1070 (_________________________) (_________________________) 1071 | | 1072 ___________|___________________________________|___________ 1073 ( | ) 1074 ( | ) 1075 ( | edge network using ) 1076 ( | routing mask FF:FF:FF:FF:FF:FF::/48 ) 1077 ( | ) 1078 ( | ) 1079 ( =============== firewall associates ) 1080 ( |___|___|___| "from host X" = "from ::SID:IIDx" ) 1081 ( |_|___|___|_| "to host X" = "to ::SID:IIDx" ) 1082 ( |___|___|___| "from host Z" = "to ::SID:IIDx, CIDx" ) 1083 ( |_|___|___|_| "to host Z" = "from ::SID:IIDx, CIDx" ) 1084 ( | ) 1085 (___________|_______________________________________________) 1086 | 1087 --------+-----+---------------+------access link------+---------- 1088 | | | 1089 +---------------+ +------------------+ +------------------+ 1090 | access router | | host X using | | host Y using | 1091 | advertises | | IP address bunch | | IP address bunch | 1092 | PP1:SID::/64 | | PP1:SID:IIDx | | PP1:SID:IIDy | 1093 | PP2:SID::/64 | | PP2:SID:IIDx | | PP2:SID:IIDy | 1094 | | | +context ID CIDx | | +context ID CIDy | 1095 +---------------+ +------------------+ +------------------+ 1097 Figure 6: Operation of a firewall in the presence of Six/One 1099 5. Discussion 1101 This section attends to the feasibility of Six/One as a universal 1102 solution for the routing and addressing problem. It discusses the 1103 incentives Internet players have to deploy and use Six/One, and it 1104 describes a transition plan for moving the current Internet towards a 1105 Six/One-capable Internet. The section furthermore explains how Six/ 1106 One could help bringing forward a universal solution for source 1107 address validation. 1109 5.1. Incentives for Deployment 1111 The success of a solution for the routing and addressing problem 1112 hinges on its acceptance by the three Internet players -- end users, 1113 edge network operators, and providers. Acceptance, in turn, depends 1114 on the degree to which a solution satisfies the objectives of a 1115 player relative to the costs that a deployment entails for the 1116 player. 1118 In the case of Six/One, the main hurdle for universal deployment is a 1119 widespread support in hosts. At first glance, it may seem difficult 1120 to enforce such widespread support, in particular since a significant 1121 part of Six/One's functionality is for the benefit of edge network 1122 operators and does not directly benefit the hosts themselves. On the 1123 other hand, end users are oftentimes not directly involved in host 1124 upgrades. Mobile phones or Internet-ready entertainment equipment 1125 typically have a rather short lifetime, which makes a medium-term 1126 introduction of new networking protocols well feasible. Major 1127 operating systems for personal computers incorporate highly automated 1128 upgrade routines, which allows for even short-term introduction of 1129 new software. The introduction of new host-based networking 1130 technology may hence turn out to be more facile than the introduction 1131 of technology that requires technical, and oftentimes also 1132 administrative, co-operation of edge network operators or providers. 1134 Edge network operators are likely to benefit most from Six/One. It is 1135 therefore legitimate to expect them to willingly adopt the practices 1136 recommended in Section 4. 1138 Providers are expected to embrace the introduction of Six/One because 1139 the sole use of provider-dependent addressing space inside the 1140 transit domain will facilitate a smaller routing table size and less 1141 frequent routing table updates. This benefit is considered 1142 paramount, and therefore likely to compensate for the small cost of 1143 slightly higher packet sizes, which Six/One incurs due to in-band 1144 signaling for context setup and identification. Barring the 1145 increased packet size, providers remain unaffected by an introduction 1146 of Six/One. A provider may at most agree to perform address rewriting 1147 on behalf of an edge network. Such a co-operation would take place 1148 as part of a business relationship between the provider and the edge 1149 network, and would hence be driven by economic objectives. 1151 5.2. Transition 1153 Transition towards a widespread deployment of Six/One could proceed 1154 in two phases. 1156 1. In the first phase, support for Six/One will be introduced into 1157 hosts, and edge network operators will gradually adopt the 1158 practices recommended in Section 4. To avoid disruptions of 1159 communication sessions with legacy correspondent hosts, hosts 1160 with support for Six/One rewrite an address only after a received 1161 Context Setup option in an IPv6 Destination Options extension 1162 header indicates that also the correspondent host supports Six/ 1163 One. For the same reason, routers refrain from rewriting an 1164 address in packets that do not contain a Context ID option in an 1165 IPv6 Destination Options extension header. The Context ID 1166 option, too, indicates bilateral Six/One support since it is used 1167 only by Six/One hosts that have received a Context Setup option 1168 from the correspondent host. 1170 2. The second phase begins when there is reasonably widespread Six/ 1171 One support in hosts. Both host and edge networks can now begin 1172 to initiate address rewrites. 1174 To aid transition, two operational modes should be differentiated for 1175 Six/One software on hosts. In "conservative mode", Six/One will only 1176 adapt to address rewrites that were performed in the network or by 1177 the instance of Six/One on a correspondent host. Six/One software 1178 running in conservative mode should also provide support for legacy 1179 correspondent hosts, which do not understand Context Setup and 1180 Context ID options in an IPv6 Destination Options extension header. 1182 More sophisticated Six/One software may further support a 1183 "progressive mode", in which address rewrites may also be initiated 1184 by the Six/One instance on the host itself. While conservative mode 1185 provides the necessary functionality to adapt to network-side address 1186 rewrites, progressive mode additionally enables a host to replace the 1187 source address selected by an application with another address that 1188 corresponds to a different provider. Progressive mode is useful when 1189 a Six/One instance is aware of alternative providers and the quality 1190 of service these providers deliver. For example, if a provider 1191 selected at application level has recently performed poorly or become 1192 defunct, Six/One may autonomously rewrite the source address in 1193 packets received from the application in order to suggest to the edge 1194 network that the packets be routed via a different provider. During 1195 the first transition phase, Six/One software on hosts should operate 1196 in conservative mode only, since Six/One support on a correspondent 1197 host can then not necessarily be expected. Six/One software that 1198 supports progressive mode may be switched to that mode when the 1199 second transition phase begins. 1201 End users benefit from Six/One in that the protocol enables their 1202 hosts to suggest packets to be routed via a preferred provider. End 1203 users can hence be expected not to hinder Six/One-related host 1204 upgrades. Host upgrades will furthermore occur mostly transparently 1205 to the end users, either through replacement of old networking 1206 equipment, or through automated software upgrades. The introduction 1207 of Six/One software in the first transition phase will hence occur 1208 rather smoothly. Adoption of the recommended practices in edge 1209 networks will be driven by the prospects of reduced network 1210 reconfiguration costs during rehoming, which apply independently of 1211 Six/One support on hosts or the practices of other edge network 1212 operators. Multi-homed edge network will further be motivated by the 1213 prospective ability to rewrite addresses as of the second transition 1214 phase, since this ability will accommodate their traffic engineering 1215 strategies. 1217 5.3. Easing Universal Source Address Validation 1219 Protection against IP spoofing has until today never become 1220 universal. The reason for this is that available source address 1221 validation techniques such as ingress filtering are missing 1222 deployment incentives for edge network operators or providers. Six/ 1223 One can help in this regard because it enables routers to rewrite 1224 subnet prefixes in packets' source addresses, thus automatically 1225 fixing subnet prefixes that are topologically incorrect. 1227 In a typical deployment of Six/One, border routers -- either inside 1228 the edge network or in the providers's network -- ensure that the 1229 source addresses in packets leaving the edge network have the routing 1230 prefix of the provider they are going through. (Failure to do so 1231 would prevent return traffic to go via the same provider and hence 1232 defeat efficient provider fail-over.) An efficient way of 1233 implementing a routing prefix check would be for a border router to 1234 simply overwrite the routing prefix in the source address of every 1235 packet leaving the edge network. Access routers then only need to 1236 verify the subnet ID in the packets they forward. This is a simple 1237 task given that there is only a single, stable subnet ID per link. 1238 In contrast to ingress filtering today, this task would not require 1239 reconfiguration when the edge network rehomes. 1241 6. Security Considerations 1243 This section addresses potential security threats for Six/One, and it 1244 describes how Six/One protects against these threats. 1246 o Impersonation. The default address bunch protection mechanism 1247 described in Section 3.4 mitigates the threat of impersonation 1248 attacks. Alternatively, if Six/One is combined with a host 1249 mobility, host multi-homing, or host identity protocol, such as 1250 Mobile IPv6 or the Host Identity Protocol, the address ownership 1251 proof performed by that protocol can replace the default address 1252 ownership proof of Six/One, as described in Section 3.4. 1254 o Inverse impersonation. In an inverse impersonation attack, an 1255 attacker tricks a correspondent host into believing that it is 1256 communicating with the attacker, while in fact it communicates 1257 with a victim host. This attack would require the attacker to 1258 build an address bunch that includes the victim host's address. 1259 Such fraud that is prevented by the default address bunch 1260 protection mechanism described in Section 3.4. 1262 o Redirection-based flooding. The protection against impersonation 1263 described in Section 3.4 mitigates attacks against a specific 1264 victim host because an attacker cannot easily construct an address 1265 bunch that includes the victim host's address. Redirection-based 1266 flooding attacks against networks could be protected against 1267 through reachability verification -- as it is done in Shim6 or 1268 Mobile IPv6, for example. On the other hand, redirection-based 1269 flooding attacks require IP spoofing. So given the fact that Six/ 1270 One eases universal source address validation (see Section 5.3), 1271 extra signaling for flooding prevention might actually no longer 1272 be necessary. 1274 7. IANA Considerations 1276 This document has no actions for IANA. 1278 8. Acknowledgment 1280 The author would like to thank Jari Arkko, Pekka Nikander, Steven 1281 Blake, Lars Westberg, Mikko Sarela, Mark Doll, Lixia Zhang, Tony Li, 1282 Geoff Huston, Brian E. Carpenter, Marcelo Bagnulo, Erik Nordmark, 1283 Lars Eggert, Pekka Savola, Magnus Westerlund, Jonne Soininen, Loa 1284 Andersson, David Ward, John Scudder, Gert Doering, Olaf Kolkman, Stig 1285 Venaas, Thomas C. Schmidt, Kotikalapudi Sriram, Jordi Palet, Andras 1286 Csaszar, Jan M. Melen, Petri Jokela, Patrik Salmela, Borje Ohlman, 1287 Anders Eriksson, and Attila Mihaly for valuable feedback on the 1288 solution to the routing and addressing problem presented in this 1289 document, and for interesting discussions on the routing and 1290 addressing problem as such. 1292 This document was generated using the XML2RFC tool. 1294 9. References 1296 9.1. Normative References 1298 [ietf-shim6-hba] 1299 Bagnulo, M., "Hash Based Addresses (HBA)", IETF Internet 1300 draft draft-ietf-shim6-hba-03.txt (work in progress), 1301 June 2007. 1303 [rfc2119-rfc-keywords] 1304 Bradner, S., "Key Words for Use in RFCs to Indicate 1305 Requirement Levels", IETF BCP 14, RFC 2119, March 1997. 1307 [rfc3972-cga] 1308 Aura, T., "Cryptographically Generated Addresses (CGA)", 1309 IETF Request for Comments 3972, March 2005. 1311 9.2. Informative References 1313 [ietf-shim6-proto] 1314 Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1315 Shim Protocol for IPv6", IETF Internet draft 1316 draft-ietf-shim6-proto-08.txt (work in progress), 1317 May 2007. 1319 [nikander-ram-generix-proxying] 1320 Nikander, P., "Generic Proxying as a Deployment Tool 1321 (GEPROD)", IETF Internet draft 1322 draft-nikander-ram-generix-proxying-00.txt (work in 1323 progress), January 2007. 1325 [odell-8+8] 1326 O'Dell, M., "8+8 - An Alternate Addressing Architecture 1327 for IPv6", IETF Internet draft draft-odell-8+8-00.txt 1328 (work in progress), October 1996. 1330 [rfc4191-ip6-architecture] 1331 Hinden, R. and S. Deering, "IP Version 6 Addressing 1332 Architecture", IETF RFC 4191, February 2006. 1334 [rfc4193-unique-local-ip6] 1335 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1336 Addresses", IETF RFC 4193, October 2005. 1338 [schuetz-nid-arch] 1339 Schuetz, S., Winter, R., Burness, L., Eardley, P., and B. 1341 Ahlgren, "Node Identity Internetworking Architecture", 1342 IETF Internet draft draft-schuetz-nid-arch-00.txt (work in 1343 progress), September 2007. 1345 Appendix A. Change Log 1347 The following is a list of technical changes that were made from 1348 version 00 to version 01 of the document. Editorial revisions are 1349 not explicitly mentioned. 1351 o Section 4.3 -- Clarified support for preconfigured addresses in 1352 applications. 1354 o Section 5.2 -- Enhanced backward-compatibility: Hosts and routers 1355 rewrite addresses only after both end hosts are known to support 1356 Six/One. 1358 Author's Address 1360 Christian Vogt 1361 Ericsson Research, NomadicLab 1362 Hirsalantie 11 1363 02420 Jorvas 1364 Finland 1366 Email: christian.vogt@ericsson.com