idnits 2.17.1 draft-meyer-loc-id-implications-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2009) is 5572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-02 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-10 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-03 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-04 == Outdated reference: A later version (-09) exists of draft-templin-ranger-00 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-11 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Meyer 2 Internet-Draft D. Lewis 3 Intended status: Informational Cisco 4 Expires: July 27, 2009 January 23, 2009 6 Architectural Implications of Locator/ID Separation 7 draft-meyer-loc-id-implications-01.txt 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. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on July 27, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 Recent work on Locator/ID Separation has focused primarily on the 47 control plane protocols concerned with finding Identifier-to-Locator 48 mappings. However, experience gained with a trial deployment of a 49 system designed to implement Locator/ID Separation has revealed two 50 general classes of problems that must be resolved after the mapping 51 is found: The Locator Path Liveness Problem and the State 52 Synchronization Problem. These problems have implications for the 53 data plane as well as the control plane. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Problem Space . . . . . . . . . . . . . . . . . . . . . . 4 59 3. The Locator Path Liveness Problem . . . . . . . . . . . . . . 4 60 3.1. The Multi-Exit Problem . . . . . . . . . . . . . . . . . . 7 61 3.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2.1. Complexity of Host-Based Probing . . . . . . . . . . . 7 63 3.2.2. Complexity of Network-Based Probing . . . . . . . . . 8 64 3.3. Possible Optimizations . . . . . . . . . . . . . . . . . . 8 65 3.4. Security Issues . . . . . . . . . . . . . . . . . . . . . 10 66 4. Site-Based State Synchronization . . . . . . . . . . . . . . . 11 67 4.1. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Locator/ID Separation (hereafter Loc/ID split) has been proposed as 79 an architectural enhancement to the Internet architecture to 80 facilitate, among other things, scaling of the global routing system 81 [RFC1498][Chiappa99][Fuller06][RFC4984]. The basic idea is that the 82 current number space (the IPv4/IPv6 address space) is overloaded with 83 both location and identity semantics. One consequence of this 84 overloading is that it is difficult to assign routing locators 85 (RLOCs) in a way that is congruent with the underlying network 86 topology; this makes aggregation difficult, if not impossible. This 87 property is sometimes referred to as Rekhter's Law, and is frequently 88 formulated as follows: 90 "Addressing can follow topology or topology can follow 91 addressing. Choose one." 93 Endpoint Identifiers (EIDs), on the other hand, are typically 94 assigned without regard to the underlying network topology (for 95 example, Host Identity Tags [RFC4423]). This makes it difficult for 96 a single numbering space to efficiently serve both routing locator 97 and endpoint identifier roles. 99 Locator/Identity Separation can be used to decouple the allocation of 100 of EIDs from RLOCs, enabling the RLOC space to be aggregated 101 aggressively (by aligning RLOC allocations with the underlying 102 network topology). The positive effect of such aggregation would be 103 to control the growth of global routing state. Note that aggregation 104 in the EID space may also an issue, but as of this writing hasn't 105 been explored extensively. 107 Recent work on Locator/ID Separation has focused almost exclusively 108 on control plane protocols for finding Identifier-to-Locator mappings 109 (for example, [I-D.fuller-lisp-alt][I-D.jen-apt] 110 [I-D.lear-lisp-nerd]). However, experience gained with a trial 111 deployment of a system designed to implement Locator/ID Separation 112 has revealed two general classes of problems that must be resolved 113 after the mapping is found: The Locator Path Liveness Problem and the 114 State Synchronization Problem. These problems have implications for 115 the data plane as well as the control plane. 117 This document focuses on the Locator Path Liveness and State 118 Synchronization problems, and is organized as follows: Section 2 119 provides an overview of the problem space. Section 3 discusses the 120 Locator Path Liveness problem, and Section 4 discusses the State 121 Synchronization problem. Finally, Section 5 provides a few 122 conclusions. 124 2. The Problem Space 126 Decoupling Location and Identity has profound implications both the 127 control and data planes. In particular, decoupling location from 128 identity leads to the two difficult problems: first, given a set of 129 source locators and a set of destination locators, it must be 130 possible to determine if a particular destination locator is 131 reachable. We refer to this general problem as the Locator Path 132 Liveness Problem. The Locator Path Liveness Problem is exhibited in 133 host-based architectures such as SHIM6 [I-D.ietf-shim6-proto]) and 134 HIP (Section 1.2 of [OPENHIP] describes an architecture in which "the 135 failure detection daemon (reapd) is designed to be reused across HIP 136 and shim6"), and network-based architectures such as RANGER 137 [I-D.templin-ranger], eFIT [EFIT] and [LISP]). The "Hybrid 138 Rewriting" class of architectures such as GSE [ODell97] exhibit a 139 variant on the problem. Locator Liveness is discussed in detail in 140 Section 3. 142 The second problem discussed in this document is that mapping state 143 may need to be shared among network elements; this is as opposed to 144 the determining if the locator itself is up or down. This is 145 referred to as the Site-Based State Synchronization Problem, and is 146 specific to network-based architectures. The Site-Based State 147 Synchronization problem is discussed in Section 4. 149 3. The Locator Path Liveness Problem 151 The Locator Path Liveness Problem has been studied in various 152 contexts [IANNONE08] [BARRE08] [OLIVA08] [OPENHIP] 153 [I-D.ietf-shim6-failure-detection], and can be stated as 154 follows: 156 Given a set of source locators and a set of destination 157 locators, can bi-directional connectivity be 158 determined between the address pairs? 161 A simple example illustrates the problem. Consider the scenario 162 depicted in Figure 1. Here a site S0 is multihomed to provider A and 163 provider B. Further, suppose that S0 has a Provider Assigned (PA) 164 locator from provider A (call it La) and a PA locator, Lb, from 165 provider B. Suppose that provider A peers with provider B. In this 166 case, S0 might "advertise" that its EID-prefixes can be reached 167 through nodes La and Lb (either via DNS, explicit protocol message 168 such as a Map-Reply message [LISP], or other method) to its 169 correspondent sites. 171 Now, suppose that a correspondent site S1 is connected to provider C, 172 and that S0 has told S1 that it can reach S0 on either La or Lb. 173 Suppose further that S1 chooses La to reach S0, so that packets 174 sourced from S1 destined for S0 traverse the path S1->C->B->A->S0. 175 Note that if connectivity between provider B and provider A is 176 disrupted, either for business or technical reasons, La will not be 177 reachable from S1. In this case, S1 must detect that La is no longer 178 reachable and use Lb to restore connectivity (in the event that S1 179 wants to restore connectivity; in today's Internet, S0 would continue 180 to be unreachable). 182 S1 183 | 184 | 185 C 186 | 187 | 188 A-----------------B 189 \ peering link / 190 \ / 191 \ / 192 \ / 193 \ / 194 La Lb 195 \ / 196 S0 198 Figure 1: Reachability Failure 200 The Locator Path Liveness problem arises in subtly different ways, 201 depending on the contents of the mapping database (i.e., EIDs, RLOCs, 202 or some combination of these), who queries the database (host or 203 network element), and how knowledge is distributed between hosts and 204 routing elements. Note that in general, Locator Path Liveness must 205 be tested in the data plane (although an implementation might take 206 advantage of various "hints; see Section 3.3). 208 Host-Based Architectures: In host-based architectures (e.g., SHIM6 209 [I-D.ietf-shim6-proto]), the problem arises because queries to the 210 database (DNS in this case) return "addresses" that can be thought 211 of as a concatenation of the RLOC and EID. Because a host is 212 anticipated to have multiple such "addresses" (at least in the 213 SHIM6 case), it must choose a working pair 214 from among its potential source addresses and its correspondent 215 destination addresses. REAP [I-D.ietf-shim6-failure-detection] is 216 a probe-based reachability protocol that is designed to address 217 this problem. 219 Hybrid Network-Based Rewriting Architectures: In hybrid network- 220 based rewriting architectures (such as GSE [ODell97]), the problem 221 arises because there is a knowledge asymmetry between the host and 222 routing. Specifically, while the host is responsible for 223 selecting the destination Routing Goop (RG) (i.e., the ingress 224 point to the destination domain, essentially the destination 225 RLOC), it is routing that selects the source RG. So while the IGP 226 routing in a domain can be intelligent about egress points from 227 the domain, it is the destination address, chosen by the host, 228 that selects the ingress point in the destination domain. 230 This asymmetry gives rise to the following problem: Hosts will 231 likely want information, at some granularity, about which 232 pairs currently work. However, the host has 233 no information about how many RGs are available to the site or if 234 they are currently reachable. So the host cannot test the set of 235 pairs for active paths. On the other hand, 236 the routing system can't either, unless it snoops on TCP 237 connections (which doesn't deal with asymmetric paths, UDP flows, 238 or unidirectional flows). Section 4.2 of [Zhang06] discusses this 239 issue from a slightly different point of view. 241 It is worth noting that unlike most "modern" descriptions of how 242 GSE uses the DNS [Zhang06], the original GSE design 243 [ODell97][ODell08] envisioned that the DNS would have a new 244 resource record type, the RG record, to carry a site's RGs. Hosts 245 would only have AAAA records. The idea was that for a given 246 destination domain, a host in the source domain would compute the 247 Cartesian Product {RGs}x{A4s}. Thus alternate path sensing would 248 become a a matter of local policy, and not hard-wired by the 249 destination domain (or whoever happens to be authoritative for the 250 destination domain's names). Notice, however that even with the 251 introduction of the RG resource record, the knowledge asymmetry 252 remains. 254 Network-Based Map-and-Encap Archtectures: In the case of map-and- 255 encap network-based architectures, the problem arises because the 256 mapping element (e.g., Ingress Tunnel Router, or ITR) must choose 257 among the RLOCs it has learned for a given EID-prefix. Thus an 258 ITR can choose among the RLOCs associated with a given EID prefix, 259 and a host may choose among multiple EIDs. However, a host cannot 260 choose among the possible RLOCs; it simply has no access to that 261 information (and even if it could, it would have no way to use 262 that information). Hence if the ITR chooses a RLOC that is not 263 reachable, traffic to the destination site will be blackholed, and 264 the host is left with no recourse. 266 3.1. The Multi-Exit Problem 268 The Multi-Exit Problem (MEP) arises when a site has two or more ITRs 269 and there is a difference in destination RLOC reachability between 270 the ITRs. For example, a site might have two ITRs, one which has 271 connectivity to the destination RLOC, and one which doesn't. In this 272 case, the host's packet will be carried by the site's internal 273 routing (Interior Gateway Protocol, or IGP) to one of the exit 274 points, as expected. However, since the IGP has no knowledge of 275 locator liveness, and the host has limited ability to choose its exit 276 (which may in any event be overridden by site routing), packets may 277 be routed to a ITR that can not deliver them to the destination even 278 though some ITR at the site can successfully deliver such packets. 280 As illustrated by the example above, the MEP arises because neither 281 party (i.e., the host or the site's routing infrastructure) has both 282 the knowledge or control necessary to detect the problem and route 283 the packet accordingly. Note that while the MEP can arise without 284 Locator/ID separation (for example, in the case in which site's 285 border routers are taking default from their upstreams), the MEP can 286 arise even when the site's routers have complete routing (e.g., a 287 copy of the DFZ BGP table). 289 3.2. Complexity 291 The complexity of testing Locator Path Liveness in the data plane 292 (i.e., probing) is roughly O(M*N), where there are M source addresses 293 and N destination addresses. The following sections more closely 294 analyze the complexity of host-based and network-based liveness 295 probing. Note that the complexity described here is "worst-case". 296 It is anticipated that implementations will develop heuristics such 297 as those described in Section 3.3 to efficiently deal with Locator 298 Path Liveness. 300 3.2.1. Complexity of Host-Based Probing 302 Host-based implementations must keep per-correspondent host liveness 303 state. The complexity of probing in a host-based implementation can 304 be thought of as follows: 306 Let C = the number of correspondent hosts 307 Let D_i = the number of destination locators for host C_i 308 Let S = the number of source locators 310 Then the complexity of host-based probing, P_host, is 312 O(P_host), where P_host = S*sum(D_i), i = 0...C-1 314 3.2.2. Complexity of Network-Based Probing 316 Network-based implementations must keep per-destination egress point 317 liveness. The complexity of probing in a network-based 318 implementation can be thought of as follows: 320 Let N = the number of EID-prefixes in a network element's 321 cache 322 Let L_i = the number of locators for EID-prefix N_i 323 Let M = the number of source locators 325 Then the complexity of network-based probing, P_network, can 326 be described as 328 O(P_network), where P_network = M*sum(L_i), i = 0...N-1 330 Note that a network-based probing scheme might have an advantage here 331 because a single EID-prefix may cover many correspondent hosts. That 332 is, sum(L_i), i = 0...N-1 < sum(D_i), i = 0...C-1 334 3.3. Possible Optimizations 336 The previous sections analyzed the complexity of explicitly probing 337 to assess Locator Path Liveness. To mitigate this complexity, an 338 implementation might rely on the various "hints" to assess Locator 339 Path Liveness. The following sections, while not intended to be an 340 exhaustive survey, outline some of the Locator Path Liveness hints an 341 implementation may utilize. 343 Data Traffic: When data is received, an implementation might assume 344 that the source of that traffic is reachable, and as such probing 345 might not be needed. Of course, this is, at best, a 346 unidirectional "hint" that an implementation might use to 347 determine locator liveness. Only a complete round trip, wherein 348 the distant site says something back to the local site which the 349 local site originally sent to the distant site, can one then 350 guarantee that the distant site can hear the local site. 352 A variation on this theme is to "piggyback" liveness testing on 353 user data traffic, by adding a Solicit-User-Probe-Reply bit, that 354 tells the far end to send back the next user data packet(s) with 355 the outbound nonce, and a User-Probe-Reply bit set. Of course, 356 this optimization depends on the existence of some traffic (even 357 if not for the same connection) going between pairs of border 358 elements. That is, if a particular pair has only traffic in one 359 direction, this method fails. In addition, it requires extra 360 processing on user data packets, extra overhead in the packets (a 361 field, some bits), and extra protocol complication. Of course, 362 such piggybacking only provides the view from remote domain, not 363 whether the locator is actually reachable from the recipient of 364 the "User-Probe-Bit". 366 Protocol Control Messages: If a protocol control message is received 367 (for example, a Map-Reply), an implementation may conclude that 368 the source of that is reachable. Again, in the best case, this is 369 only a hint, because receipt of the control message proves only 370 unidirectional connectivity. 372 Piggybacking Liveness Indications: A network-based architecture 373 might piggyback indication of intra-domain locator liveness on 374 other data and/or protocol messages. An example of this approach 375 is LISP's use of loc-reach bits to indicate which Egress Tunnel 376 Routers in a domain are up from the domain's perspective. 378 Existence of the Locator in underlying routing: A device which is 379 responsible for locator liveness can utilize underlying routing to 380 determine if the locator is at all available. If the network 381 prefix (or a covering aggregate) for the destination locator is 382 NOT found in underlying routing, then the path will not be 383 available. This is at best a negative detection, it can show when 384 a path is not available, but liveness of a particular locator. A 385 given locator may still be unavailable and this not be shown in 386 routing, due to data plane filtering, or the reachability being 387 hidden by aggregation of the particular locator prefix. 389 Positive Feedback From Other Protocols: An implementation may be 390 able to deduce some forms of reachability from other protocols. 391 For example, TCP might indicate to the IP layer that it believes 392 that there is bidirectional connectivity between a given address 393 pair. This might be signaled to the source when it receives a 394 SYN-ACK from the destination RLOC. As pointed out in 395 [I-D.ietf-shim6-failure-detection], this is similar to how IPv6 396 Neighbor Unreachability Detection, which can be avoided when upper 397 layers provide information about bidirectional connectivity 398 [RFC4861]. 400 If an implementation has access to higher layer protocols such as 401 BGP, it might get a hint as to the reachability of a given 402 locator. In the case of BGP, an implementation might conclude 403 that the locator is reachable if there is a covering prefix in the 404 BGP Routing Information Base (RIB). Again, this is a hint, 405 because the correspondent host may be down. 407 Timeouts: An implementation may be able to deduce some forms of 408 Unreachability from timeouts of other protocols.For example, TCP 409 might indicate that there is a lack of connectivity because it is 410 not getting ACKs.Of course, this signal is overloaded: there may 411 simply be congestion. 413 ICMP Messages: While ICMP is an available signalling protocol, due 414 to its lack of security (in particular, ease of spoofing 415 [I-D.ietf-tcpm-icmp-attacks]) and the fact that common policy is 416 to block or rate limited ICMP, its utility has been somewhat 417 marginalized (see Section 3.4). As such, ICMP may be used as a 418 hint but beyond that, an implementation can not rely on ICMP as a 419 signalling mechanism. 421 QQQ: Again, when do I know a locator is up? If I probe and the 422 response is positive, does that mean its up (i.e., it can go down in 423 the interim, so what is the time granularity, and what effect does 424 that have on efficiency? 426 In general, depending on end-to-end liveness indications are 427 applicable only to host-based solutions (e.g., 428 [I-D.ietf-shim6-proto]). A network-based implementation may rely on 429 higher layer protocols to indicate liveness (for example, an 430 implementation may be able deduce a limited form of reachability from 431 the existence of a BGP route covering the destination RLOC), but 432 these too can only be used as hints. In the general case, however, 433 an architecture that implements Loc/ID split (either host-based or 434 network-based) will need to test Locator Path Liveness in the data 435 plane 437 3.4. Security Issues 439 Mere inspection of insecure traffic may lead to false negative 440 detection because of the insertion of malicious traffic. For 441 instance, packets that masquerade as coming from a site may tamper 442 with the loc-reach-bits, making the site's locators appear 443 unreachable when in fact they are reachable [LISP]. 445 ICMP Messages: ICMP messages are easily spoofable 446 [I-D.ietf-tcpm-icmp-attacks], so they may be exploited to provide 447 false negatives. However, they are also rate limited and often 448 outright disabled, leaving a site sending data to a remote RLOC 449 under the impression that the RLOC is reachable (a false positive 450 side effect of such filtering). 452 Existence of the Locator in the BGP RIB: This vulnerability is 453 shared by non-Loc/ID split architectures (need reference to 454 Pakistani-youtube example as a way compromised routing can break 455 path liveness). 457 Aside from the ability to mislead a poorly implemented probing 458 mechanism with data spoofing, probing creates a fundamentally 459 unscalable relationship between site pairs (see Section 3.2). This 460 leads to both implicit (unscalable) and explicit (vulnerable to probe 461 floods) Denial of Service vulnerability in the systems receiving 462 probe requests. 464 Finally, note that in the case of network-based Loc/ID separation 465 architectures, the RLOCs of border elements represent reachability on 466 behalf of entire site. As a result, failure to detect path liveness 467 can disrupt connectivity to the entire site. On the other hand, in 468 host-based Loc/ID separation architectures, only individual hosts are 469 compromised. 471 4. Site-Based State Synchronization 473 The Site-Based State Synchronization problem is specific to network- 474 based Loc/ID split architectures. There are two kinds of state 475 synchronization that might need to be performed: mapping state 476 synchronization and locator liveness synchronization. 478 The Site-Based State Synchronization problem can most easily be 479 demonstrated by a simple example. Consider the following case: A 480 site has two ITRs; one ITR is on the active path and the other ITR is 481 on a backup path. In this case, all traffic egressing from the site 482 traverses the ITR on the active path, and as a result that ITR is 483 caching the mapping state for all of the active flows. The ITR on 484 the backup path has no mapping state. Now, when the ITR on the 485 active path fails, traffic is naturally shifted to the ITR on the 486 backup path. If the now active ITR hasn't synchronized its state 487 with the previously active ITR(s), then the newly active ITR has to 488 reconstruct the mapping state for the flows that were traversing the 489 failed ITR. In particular, the failure, which is local to the site, 490 requires the now active ITR to go off-site to reconstruct the state. 492 4.1. Complexity 494 TBD 496 5. Conclusions 498 Architectures that implement Locator/ID Separation, either host or 499 network based, need to evaluate carefully the complexity inherent in 500 determining Locator Path Liveness. The complexity of mapping state 501 synchronization is an additional concern for network-based 502 architectures. 504 6. Acknowledgments 506 Shane Amante, Scott Brim, Noel Chiappa, John Day, Dino Farinacci, 507 Vince Fuller, Mike O'Dell, Andrew Partan, and John Zwiebel provided 508 insightful comments on early versions of this document. A special 509 thanks goes to Mary Nickum for her attention to detail and effort in 510 editing this document. 512 7. IANA Considersations 514 This document creates no new requirements on IANA namespaces 515 [RFC2434]. 517 8. References 519 8.1. Normative References 521 [Chiappa99] 522 Chiappa, N., "Endpoints and Endpoint Names: A Proposed 523 Enhancement to the Internet Architecture", xxx 1999, 524 . 526 [EFIT] Massey, D., "A Proposal for Scalable Internet Routing & 527 Addressing", Feb 2007, . 530 [Fuller06] 531 Fuller, V., "Scaling issues with ipv6 routing+ 532 multihoming", Oct 2006, . 535 [I-D.fuller-lisp-alt] 536 Farinacci, D., "LISP Alternative Topology (LISP+ALT)", 537 draft-fuller-lisp-alt-02 (work in progress), April 2008. 539 [I-D.ietf-shim6-failure-detection] 540 Arkko, J. and I. Beijnum, "Failure Detection and Locator 541 Pair Exploration Protocol for IPv6 Multihoming", 542 draft-ietf-shim6-failure-detection-13 (work in progress), 543 June 2008. 545 [I-D.ietf-shim6-proto] 546 Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 547 Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work 548 in progress), February 2008. 550 [I-D.ietf-tcpm-icmp-attacks] 551 Gont, F., "ICMP attacks against TCP", 552 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 553 March 2008. 555 [I-D.jen-apt] 556 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 557 L. Zhang, "APT: A Practical Transit Mapping Service", 558 draft-jen-apt-01 (work in progress), November 2007. 560 [I-D.lear-lisp-nerd] 561 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 562 draft-lear-lisp-nerd-04 (work in progress), April 2008. 564 [I-D.templin-ranger] 565 Templin, F., "Routing and Addressing in Next-Generation 566 EnteRprises (RANGER)", draft-templin-ranger-00 (work in 567 progress), October 2008. 569 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 570 "Locator/ID Separation Protocol (LISP)", 571 draft-farinacci-lisp-11 (work in progress), Jan 2009. 573 [ODell08] Odell, M., "GSE - An Alternate Addressing Architecture for 574 IPv6 (Private Communication)", Dec 2008. 576 [ODell97] Odell, M., "GSE - An Alternate Addressing Architecture for 577 IPv6", Oct 2006, . 580 [OPENHIP] Ahrenholz, J. and T. Henderson, "shim6 manual (html 581 version)", 2007, . 583 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 584 Destinations", RFC 1498, August 1993. 586 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 587 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 588 October 1998. 590 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 591 (HIP) Architecture", RFC 4423, May 2006. 593 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 594 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 595 September 2007. 597 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 598 Workshop on Routing and Addressing", RFC 4984, 599 September 2007. 601 [Zhang06] Zhang, L., "An Overview of Multihoming and Open Issues in 602 GSE", Sept 2006, 603 . 605 8.2. Informative References 607 [BARRE08] Barre, S. and O. Bonaventure, "Improved Path Exploration 608 in shim6-based Multihoming", 2008. 610 [IANNONE08] 611 Iannone, L., Saucez, D., and O. Bonaventure, "Implementing 612 the Locator/ID Separation Protocol: Design and 613 Experience", 2008. 615 [OLIVA08] de la Oliva, A., Bagnulo, M., Garcia-Martinez, A., and I. 616 Soto, "Performance Analysis of the REAchability Protocol 617 for IPv6 Multihoming", 2008. 619 Authors' Addresses 621 David Meyer 622 Cisco 624 Email: dmm@1-4-5.net 626 Darrel Lewis 627 Cisco 629 Email: darlewis@cisco.com