idnits 2.17.1 draft-meyer-loc-id-implications-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 606. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 Copyright Line does not match the current year -- The document date (December 8, 2008) is 5618 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 (-12) exists of draft-farinacci-lisp-10 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Meyer 3 Internet-Draft D. Lewis 4 Intended status: Informational Cisco 5 Expires: June 11, 2009 December 8, 2008 7 Architectural Implications of Locator/ID Separation 8 draft-meyer-loc-id-implications-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 11, 2009. 35 Abstract 37 Recent work on Locator/ID Separation has focused primarily on the 38 control plane protocols concerned with finding Identifier-to-Locator 39 mappings. However, experience gained with a trial deployment of a 40 system designed to implement Locator/ID Separation has revealed two 41 general classes of problems which must be resolved after the mapping 42 is found: The Locator Path Liveness Problem and the State 43 Synchronization Problem. These problems have implications for the 44 data plane as well as the control plane. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. The Problem Space . . . . . . . . . . . . . . . . . . . . . . 4 50 3. The Locator Path Liveness Problem . . . . . . . . . . . . . . 4 51 3.1. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.1.1. Complexity of Host-Based Probing . . . . . . . . . . . 7 53 3.1.2. Complexity of Network-Based Probing . . . . . . . . . 7 54 3.2. Possible Optimizations . . . . . . . . . . . . . . . . . . 7 55 3.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 9 56 4. Site-Based State Synchronization . . . . . . . . . . . . . . . 10 57 4.1. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 11 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . . . 14 67 1. Introduction 69 Locator/ID Separation (hereafter Loc/ID split) has been proposed as 70 an architectural enhancement to the Internet architecture to 71 facilitate, among other things, scaling of the global routing system 72 [RFC1498][Chiappa99][Fuller06][RFC4984]. The basic idea is that the 73 current number space (the IPv4/IPv6 address space) is overloaded with 74 both location and identity semantics. One consequence of this 75 overloading is that it is difficult to assign routing locators 76 (RLOCs) in a way that is congruent with the underlying network 77 topology; this makes aggregation difficult (if not impossible). This 78 property is sometimes referred to as Rekhter's Law, and is frequently 79 formulated as follows: 81 "Addressing can follow topology or topology can follow 82 addressing. Choose one." 84 Endpoint Identifiers (EIDs), on the other hand, are typically 85 assigned without regard to the underlying network topology (e.g., 86 Host Identity Tags [RFC4423]). This makes it difficult for a single 87 numbering space to efficiently serve the routing locator and endpoint 88 identifier roles. 90 Locator/Identity Separation can be used to decouple the allocation of 91 of EIDs from RLOCs, enabling the RLOC space to be aggressively 92 aggregated (i.e., by aligning RLOC allocations with the underlying 93 network topology). The positive effect of such aggregation would be 94 to control the growth of global routing state (note that aggregation 95 in the EID space may also an issue, but as of this writing hasn't 96 been extensively explored). 98 Recent work on Locator/ID Separation has focused almost exclusively 99 on control plane protocols for finding Identifier-to-Locator mappings 100 (for example, [I-D.fuller-lisp-alt][I-D.jen-apt] 101 [I-D.lear-lisp-nerd]). However, experience gained with a trial 102 deployment of a system designed to implement Locator/ID Separation 103 has revealed two general classes of problems which must be resolved 104 after the mapping is found: The Locator Path Liveness Problem and the 105 State Synchronization Problem. These problems have implications for 106 the data plane as well as the control plane. 108 This document focuses on the Locator Path Liveness and State 109 Synchronization problems, and is organized as follows: Section 2 110 provides an overview of the problem space. Section 3 discusses the 111 Locator Path Liveness problem, and Section 4 discusses the State 112 Synchronization problem. Finally, Section 5 provides a few 113 conclusions. 115 2. The Problem Space 117 Decoupling Location and Identity has profound implications both the 118 control and data planes. In particular, decoupling location from 119 identity leads to the two difficult problems: First, give a set of 120 source locators and a set of destination locators, it must be 121 possible to determine whether a particular destination locator is 122 reachable. We refer to this general problem as the Locator Path 123 Liveness Problem. The Locator Path Liveness Problem is exhibited in 124 host-based architectures such as SHIM6 [I-D.ietf-shim6-proto]) and 125 network-based architectures such as eFIT [EFIT] and [LISP]). The 126 "Hybrid Rewriting" class of architectures (e.g., ,GSE [ODell97]) 127 exhibit a slight variant on the problem. Locator Liveness is 128 discussed in Section 3. 130 The second problem is that mapping state may need to be shared among 131 network elements (this is as opposed to the determining if the 132 locator itself is up or down). This is referred to as the Site-Based 133 State Synchronization Problem, and is specific to network-based 134 architectures. The Site-Based State Synchronization problem is 135 discussed in Section 4. 137 3. The Locator Path Liveness Problem 139 The Locator Path Liveness Problem can be stated as follows: 141 Given a set of source locators and a set of destination 142 locators, can bidirectional connectivity be determined between 143 the address pairs? 145 A simple example illustrates the problem: Consider the scenario 146 depicted in Figure 1. Here a site S0 is multihomed to provider A and 147 provider B. Further, suppose that S0 has a Provider Assigned (PA) 148 locator from provider A (call it La) and a PA locator, Lb, from 149 provider B. Suppose that provider A peers with provider B. In this 150 case, S0 might "advertise" that its EID-prefixes can be reached 151 through nodes La and Lb (either via DNS, explicit protocol message 152 such as a Map-Reply message [LISP], or other method) to its 153 correspondent sites. 155 Now, suppose that a correspondent site S1 is connected to provider C, 156 and that S0 has told S1 that it can reach S0 on either La or Lb. 157 Suppose further that S1 chooses La to reach S0, so that packets 158 sourced from S1 destined for S0 traverse the path S1->C->B->A->S0. 159 Note that if connectivity between provider B and provider A is 160 disrupted (for either business or technical reasons), La will not be 161 reachable from S1. In this case, S1 must detect that La is no longer 162 reachable and use Lb to restore connectivity (in the event that S1 163 wants to restore connectivity; in today's Internet, would S0 would 164 continue to be unreachable). 166 S1 167 | 168 | 169 C 170 | 171 | 172 A-----------------B 173 \ peering link / 174 \ / 175 \ / 176 \ / 177 \ / 178 La Lb 179 \ / 180 S0 182 Figure 1: Reachibility Failure 184 The Locator Path Liveness problem arises in subtly different ways, 185 depending on the contents of the mapping database (i.e., EIDs, RLOCs, 186 or some combination of these), who queries the database (host or 187 network element), and how knowledge is distributed between hosts and 188 routing. Note that in general, Locator Path Liveness must be tested 189 in the data plane (although an implementation might take advantage of 190 various "hints; see Section 3.2). 192 Host-Based Architectures: In host-based architectures (e.g., SHIM6 193 [I-D.ietf-shim6-proto]), the problem arises because queries to the 194 database (DNS in this case) return "addresses" which can be 195 thought of as a concatenation of the RLOC and EID. Since a host 196 is anticipated to have multiple such "addresses" (at least in the 197 SHIM6 case), it must choose a working pair 198 from among its potential source addresses and its correspondent 199 destination addresses. REAP [I-D.ietf-shim6-failure-detection] is 200 a probe-based reachability protocol which is designed to address 201 this problem. 203 Hybrid Network-Based Rewriting Archtectures: In hybrid network-based 204 rewriting architectures (e.g., GSE [ODell97]), the problem arises 205 because there is a knowledge asymmetry between the host and 206 routing. Specifically, while the host is responsible for 207 selecting the destination Routing Goop (RG) (i.e., the ingress 208 point to the destination domain, essentially the destination 209 RLOC), it is routing that selects the source RG. So while the IGP 210 routing in a domain can be intelligent about egress points from 211 the domain, it is the destination address, chosen by the host, 212 that selects the ingress point in the destination domain. However 213 it is routing, and not the host, that knows if the destination is 214 reachable or not. Section 4.2 of [Zhang06] discusses this issue 215 from a slightly different point of view. 217 This asymmetry gives rise to the following problem: Hosts will 218 likely want information, at some granularity, about which 219 pairs currently work. However, the host has 220 no information about how many RGs are available to the site or if 221 they are currently reachable. So the host can not test the set of 222 pairs for active paths. On the other hand, 223 the routing can't either, unless it snoops on TCP connections 224 (which doesn't deal with asymmetric paths, UDP flows, or 225 unidirectional flows). 227 It is worth noting that unlike most "modern" descriptions of how 228 GSE uses the DNS (e.g., [Zhang06]), the original GSE design 229 [ODell97][ODell08] envisioned that the DNS would have a new 230 resource record type, the RG record, to carry a site's RGs. Hosts 231 would only have AAAA records. The idea was that for a given 232 destination domain, a host in the source domain would compute the 233 Cartesian Product {RGs}x{A4s}. Thus alternate path sensing would 234 become a a matter of local policy, and not hard-wired by the 235 destination domain (or whoever happens to be authoritative for the 236 destination domain's names). Notice however that even the 237 introduction of the RG resource record, the knowledge asymmetry 238 remains. 240 Network-Based Map-and-Encap Archtectures: In the case of map-and- 241 encap network-based architectures, the problem arises because the 242 mapping element (e.g., Ingress Tunnel Router, or ITR) must choose 243 among the RLOCs it has learned for a given EID-prefix. Here since 244 the ITR holds the mappings that knows the set of possible remote 245 "addresses" and not the host, the host may choose among multiple 246 EIDs, but it cannot choose among the possible RLOCs (the host has 247 no access to that information). Hence if the ITR chooses a RLOC 248 that may not be reachable, traffic to the destination site will be 249 blackholed, and the host is left with no recourse. 251 3.1. Complexity 253 The complexity of testing Locator Path Liveness in the data plane is 254 roughly O(M*N), where there are M source addresses and N destination 255 addresses. The following sections more closely analyze the 256 complexity of host-based and network-based liveness probing. 258 3.1.1. Complexity of Host-Based Probing 260 Host-based implementations must keep per-correspondent host liveness 261 state. The complexity of probing in a host-based implementation can 262 be though of as follows: 264 Let C = the number of correspondent hosts 265 Let D_i = the number of destination locators for host C_i 266 Let S = the number of source locators 268 Then the complexity of host-based probing, P_host, is 270 O(P_host), where P_host = S*sum(D_i), i = 0...C-1 272 3.1.2. Complexity of Network-Based Probing 274 Network-based implementations must keep per-destination egress point 275 liveness. The complexity of probing in a network-based 276 implementation can be thought of as follows: 278 Let N = the number of EID-prefixes in a network element's 279 cache 280 Let L_i = the number of locators for EID-prefix N_i 281 Let M = the number of source locators 283 Then the complexity of network-based probing, P_network, can 284 be described as 286 O(P_network), where P_network = M*sum(L_i), i = 0...N-1 288 Note that a network-based probing scheme might have an advantage here 289 since a single EID-prefix may cover many correspondent hosts. That 290 is, sum(L_i), i = 0...N-1 << sum(D_i), i = 0...C-1 292 3.2. Possible Optimizations 294 The previous sections analyzed the complexity of explicitly probing 295 to assess Locator Path Liveness. In order to mitigate this 296 complexity, an implementation might attempt to rely on the various 297 "hints". The following sections, while not intended to be an 298 exhaustive survey, outline some of the Locator Path Liveness hints an 299 implementation may utilize. 301 Data Traffic: When data is received, an implementation might assume 302 that the source of that traffic is reachable, and as such probing 303 might not be needed. Of course, this is at best a unidirectional 304 "hint" that an implementation might use to determine locator 305 liveness. Of course, only a complete round trip, wherein the 306 distant site says something back to the local site which the local 307 site originally sent to the distant site, can one then guarantee 308 that the distant site can hear the local site. 310 A variation on this theme is to "piggyback" liveness testing on 311 user data traffic, by adding a Solicit-User-Probe-Reply bit, which 312 tells the far end to send back the next user data packet(s) with 313 the outbound nonce, and a User-Probe-Reply bit set. Of course, 314 this optimization depends on the existence of some traffic (even 315 if not for the same connection) going between pairs of border 316 elements. That is, if a particular pair has only traffic in one 317 direction, this method fails. In addition, it requires extra 318 processing on user data packets, extra overhead in the packets (a 319 field, some bits), and extra protocol complication. Of course, 320 such piggybacking only provides the view from remote domain, not 321 whether the locator is actually reachable from the recipient of 322 the "User-Probe-Bit". 324 Protocol Control Messages: If a protocol control message is received 325 (for example, a Map-Reply), an implementation may conclude that 326 the source of that is reachable. Again, in the best case, this is 327 only a hint, since receipt of the control message proves only 328 unidirectional connectivity. 330 Piggybacking Liveness Indications: A network-based architecture 331 might piggyback indication of intra-domain locator liveness on 332 other data and/or protocol messages. An example of this approach 333 is LISP's use of loc-reach bits to indicate which Egress Tunnel 334 Routers in a domain are up (from an inside the domain 335 perspective). 337 Existence of the Locator in underlying routing: A device which is 338 responsible for locator liveness can utilize underlying routing to 339 determine if the locator is at all available. If the network 340 prefix (or a covering aggregate) for the destination locator is 341 NOT found in underlying routing, then the path will not be 342 available. This is at best a negative detection, it can show when 343 a path is not available, but liveness of a particular locator. A 344 given locator may still be unavailable and this not be shown in 345 routing, due to data plane filtering, or the reachability being 346 hidden by aggregation of the particular locator prefix. 348 Positive Feedback From Other Protocols: An implementation may be 349 able to deduce some forms of reachability from other protocols. 350 For example, TCP might indicate to the IP layer that it believes 351 that there is bidirectional connectivity between a given address 352 pair. This might be signalled to the source when it receives a 353 SYN-ACK from the destination RLOC. As pointed out in 355 [I-D.ietf-shim6-failure-detection], this is similar to how IPv6 356 Neighbor Unreachability Detection can be avoided when upper layers 357 provide information about bidirectional connectivity [RFC4861]. 359 If an implementation has access to higher layer protocols (e.g., 360 BGP), it might get a hint as to the reachability of a given 361 locator. In the case of BGP, an implementation might conclude 362 that the locator is reachable if there is a covering prefix in the 363 BGP Routing Information Base (RIB). Again, this is a hint, 364 because the correspondent host may be down. 366 Timeouts: An implementation may be able to deduce some forms of 367 Unreachability from timeouts of other protocols.For example, TCP 368 to indicate that there is a lack of connectivity because it is not 369 getting ACKs (of course, the signal is overloaded: there may be 370 congestion). 372 ICMP Messages: While ICMP is an available signalling protocol, due 373 to its lack of security (in particular, ease of spoofing 374 [I-D.ietf-tcpm-icmp-attacks]) and the fact that common policy is 375 to block or rate limited ICMP, its utility has been somewhat 376 marginalized (see Section 3.3). As such, ICMP may perhaps be used 377 as a hint but beyond that, an implementation can not rely on ICMP 378 as a signalling mechanism. 380 QQQ: Again, when do I know a locator is up? If I probe and the 381 response is positive, does that mean its up (i.e., it can go down in 382 the interim, so what is the time granularity, and what effect does 383 that have on efficiency? 385 In general, depending on end-to-end liveness indications is 386 applicable to only to host-based solutions (e.g., 387 [I-D.ietf-shim6-proto]). A network-based implementation may rely on 388 higher layer protocols to indicate liveness (for example, an 389 implementation may be able deduce a limited form of reachability from 390 the existence of a BGP route covering the destination RLOC), but 391 these too can only be used as hints. In the general case, however, 392 an architecture that implements Loc/ID split (either host-based or 393 network-based) will need to test Locator Path Liveness in the data 394 plane 396 3.3. Security Issues 398 Mere inspection of insecure traffic may lead to false negative 399 detection due to the insertion of malicious traffic. For instance, 400 packets that masquerade as coming from a site may tamper with the 401 loc-reach-bits, making the site locators look unreachable where in 402 fact they are reachable [LISP]. 404 ICMP Messages: ICMP messages are are easily spoofable 405 [I-D.ietf-tcpm-icmp-attacks], so may be exploited to provide false 406 negatives. However, they are also rate limited and often outright 407 disabled, leaving a site sending data to a remote RLOC under the 408 impression that the RLOC is reachable (as a false positive side 409 effect). 411 Existance of the Locator in the BGP RIB: This vulnerability is 412 shared by non-Loc/ID split architectures (need reference to 413 Pakistani-youtube example as a way compromised routing can break 414 path liveness). 416 Aside from the ability to mislead a poorly implemented probing 417 mechanism with data spoofing, probing creates a fundamentally 418 unscalable relationship between site pairs (see Section 3.1). This 419 leads to both implicit (unscalable) and explicit (vulnerable to probe 420 floods) Denial of Service vulnerability in the systems receiving 421 probe requests. 423 Finally, note that in the case of network-based Loc/ID split 424 architectures, the RLOCs of border elements represent reachability on 425 behalf of entire site. As a result, failure to detect path liveness 426 can disrupt connectivity to the entire site. On the other hand, in 427 host-based LIS, only individual hosts are compromised. 429 4. Site-Based State Synchronization 431 The Site-Based State Synchronization problem is specific to network- 432 based Loc/ID split architectures. There are two kinds of state 433 synchronization that might need to be performed: mapping state 434 synchronization and locator liveness synchronization. 436 The Site-Based State Synchronization problem can most easily be 437 demonstrated by a simple example. Consider the following case: A 438 site has two ITRs; one ITR is on the active path and the other ITR is 439 on a backup path. In this case, all traffic egressing from the site 440 traverses the ITR on the active path, and as a result that ITR is 441 caching the mapping state for all of the active flows. The ITR on 442 the backup path has no mapping state. Now, when the ITR on the 443 active path fails, traffic is naturally shifted to the ITR on the 444 backup path. If the now active ITR hasn't synchronized its state 445 with the previously active ITR(s), then the newly active ITR has to 446 reconstruct the mapping state for the flows that were traversing the 447 failed ITR. In particular, the failure, which is local to the site, 448 requires the now active ITR to go off-site to reconstruct the state. 450 4.1. Complexity 452 TBD 454 5. Conclusions 456 Architectures that implement Locator/ID Separation (either host or 457 network based) need to carefully evaluate the complexity inherent in 458 determining Locator Path Liveness. The complexity of mapping state 459 synchronization is an additional concern for network-based 460 architectures. 462 6. Acknowledgments 464 Scott Brim, Noel Chiappa, John Day, Dino Farinacci, Vince Fuller, 465 Mike O'Dell, Andrew Partan, and John Zwiebel provided insightful 466 comments on early versions of this document. 468 7. IANA Considersations 470 This document creates no new requirements on IANA namespaces 471 [RFC2434]. 473 8. References 475 8.1. Normative References 477 [Chiappa99] 478 Chiappa, N., "Endpoints and Endpoint Names: A Proposed 479 Enhancement to the Internet Architecture", xxx 1999. 481 [EFIT] Massey, D., "A Proposal for Scalable Internet Routing & 482 Addressing", Feb 2007. 484 [Fuller06] 485 Fuller, V., "Scaling issues with ipv6 routing+ 486 multihoming", Oct 2006. 488 [I-D.fuller-lisp-alt] 489 Farinacci, D., "LISP Alternative Topology (LISP+ALT)", 490 draft-fuller-lisp-alt-02 (work in progress), April 2008. 492 [I-D.ietf-shim6-failure-detection] 493 Arkko, J. and I. Beijnum, "Failure Detection and Locator 494 Pair Exploration Protocol for IPv6 Multihoming", 495 draft-ietf-shim6-failure-detection-13 (work in progress), 496 June 2008. 498 [I-D.ietf-shim6-proto] 499 Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 500 Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work 501 in progress), February 2008. 503 [I-D.ietf-tcpm-icmp-attacks] 504 Gont, F., "ICMP attacks against TCP", 505 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 506 March 2008. 508 [I-D.jen-apt] 509 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 510 L. Zhang, "APT: A Practical Transit Mapping Service", 511 draft-jen-apt-01 (work in progress), November 2007. 513 [I-D.lear-lisp-nerd] 514 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 515 draft-lear-lisp-nerd-04 (work in progress), April 2008. 517 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 518 "Locator/ID Separation Protocol (LISP)", 519 draft-farinacci-lisp-10 (work in progress), Oct 2008. 521 [ODell08] Odell, M., "GSE - An Alternate Addressing Architecture for 522 IPv6 (Private Communication)", Dec 2008. 524 [ODell97] Odell, M., "GSE - An Alternate Addressing Architecture for 525 IPv6", Oct 2006. 527 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 528 Destinations", RFC 1498, August 1993. 530 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 531 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 532 October 1998. 534 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 535 (HIP) Architecture", RFC 4423, May 2006. 537 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 538 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 539 September 2007. 541 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 542 Workshop on Routing and Addressing", RFC 4984, 543 September 2007. 545 [Zhang06] Zhang, L., "An Overview of Multihoming and Open Issues in 546 GSE", Sept 2006. 548 8.2. Informative References 550 Authors' Addresses 552 David Meyer 553 Cisco 555 Email: dmm@1-4-5.net 557 Darrel Lewis 558 Cisco 560 Email: darlewis@cisco.com 562 Full Copyright Statement 564 Copyright (C) The IETF Trust (2008). 566 This document is subject to the rights, licenses and restrictions 567 contained in BCP 78, and except as set forth therein, the authors 568 retain all their rights. 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 572 REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 574 AND 575 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 576 EXPRESS 577 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 578 THE USE OF 579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 580 IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 582 PURPOSE. 584 Intellectual Property 586 The IETF takes no position regarding the validity or scope of any 587 Intellectual Property Rights or other rights that might be claimed to 588 pertain to the implementation or use of the technology described in 589 this document or the extent to which any license under such rights 590 might or might not be available; nor does it represent that it has 591 made any independent effort to identify any such rights. Information 592 on the procedures with respect to rights in RFC documents can be 593 found in BCP 78 and BCP 79. 595 Copies of IPR disclosures made to the IETF Secretariat and any 596 assurances of licenses to be made available, or the result of an 597 attempt made to obtain a general license or permission for the use of 598 such proprietary rights by implementers or users of this 599 specification can be obtained from the IETF on-line IPR repository at 600 http://www.ietf.org/ipr. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights that may cover technology that may be required to implement 605 this standard. Please address the information to the IETF at 606 ietf-ipr@ietf.org.