idnits 2.17.1 draft-farinacci-lisp-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1040. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 17, 2007) is 6281 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-02) exists of draft-iab-raws-report-00 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-06 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft V. Fuller 4 Intended status: Experimental D. Oran 5 Expires: July 21, 2007 cisco Systems 6 January 17, 2007 8 Locator/ID Separation Protocol (LISP) 9 draft-farinacci-lisp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 21, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 This draft describes a simple, incremental, network-based protocol to 43 implement separation of Internet addresses into Endpoint Identifiers 44 (EIDs) and Routing Locators (RLOCs). This mechanism requires no 45 changes to host stacks and no major changes to existing database 46 infrastructures. The proposed protocol can be implemented in a 47 relatively small number of routers. 49 This proposal was stimulated by the problem statement effort at the 50 Amsterdam IAB Routing and Addressing Workshop (RAWS), which took 51 place in October 2006. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 58 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 10 60 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 12 61 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 14 62 6.1. Control-Plane Packet Format . . . . . . . . . . . . . . . 14 63 6.1.1. EID-to-RLOC Mapping Request Message . . . . . . . . . 16 64 6.1.2. EID-to-RLOC Mapping Reply Message . . . . . . . . . . 16 65 6.2. Routing Locator Selection and Reachability . . . . . . . . 16 66 7. Router Performance Considerations . . . . . . . . . . . . . . 19 67 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 20 68 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 21 69 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 21 70 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 21 71 9. Multicast Considerations . . . . . . . . . . . . . . . . . . . 23 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 73 11. Prototype Plans . . . . . . . . . . . . . . . . . . . . . . . 25 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 79 Intellectual Property and Copyright Statements . . . . . . . . . . 30 81 1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 Many years of discussion about the current IP routing and addressing 90 architecture have noted that its use of a single numbering space (the 91 "IP address") for both host transport session identification and 92 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 93 A number of scaling benefits would be realized by separating the 94 current IP address into separate spaces for Endpoint Identifiers 95 (EIDs) and Routing Locators (RLOCs); among them are: 97 1. Reduction of routing table size in the "default-free zone" (DFZ). 98 Use of a separate numbering space for RLOCs will allow them to be 99 assigned topologically (in today's Internet, RLOCs would be 100 assigned by providers at client network attachment points), 101 greatly improving aggregation and reducing the number of 102 globally-visible, routable prefixes. 104 2. Easing of renumbering burden when clients change providers. 105 Because host EIDs are numbered from a separate, non-provider- 106 assigned and non-topologically-bound space, they do not need to 107 be renumbered when a client site changes its attachment points to 108 the network. 110 3. Mobility with session survivability. Because session state is 111 associated with a persistent host EID, it should be possible for 112 a host (or a collection of hosts) to move to a different point in 113 the network topology (whether by changing providers or by 114 physically moving) without disruption of connectivity. 116 4. Traffic engineering capabilities that can be performed by network 117 elements and do not depend on injecting additional state into the 118 routing system. This will fall out of the mechanism that is used 119 to implement the EID/RLOC split (see Section 4). 121 This draft describes protocol mechanisms to achieve the desired 122 functional separation. For flexibility, the document decouples the 123 mechanism used for forwarding packets from that used to determine EID 124 to RLOC mappings. This work is in response to and intended to 125 address the problem statement that came out of the RAWS effort 126 [RAWS]. 128 This draft focuses on a router-based solution. Building the solution 129 into the network should facilitate incremental deployment of the 130 technology on the Internet. Note that while the detailed protocol 131 specification and examples in this document assume IP version 4 132 (IPv4), there is nothing in the design that precludes use of the same 133 techniques and mechanisms for IPv6. It should be possible for IPv4 134 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 135 RLOCs. 137 Related work on host-based solutions may be found described as GSE 138 [GSE], Shim6 [SHIM6], and HIP [RFC4423]. This draft attempts to not 139 compete or overlap with such solutions and the proposed protocol 140 changes are expected to complement a host-based mechanism when 141 Traffic Engineering functionality is desired. 143 Some of the design goals of this proposal include: 145 1. Minimize required changes to Internet infrastructure. 147 2. Require no hardware or software changes to end-systems (hosts). 149 3. Be incrementally deployable. 151 4. Require no router hardware changes. 153 5. Minimize router software changes. 155 6. Avoid or minimize packet loss when EID-to-RLOC mappings need to 156 be performed. 158 There are 4 variants of LISP, which differ along a spectrum of strong 159 to weak dependence on the topological nature and possible need for 160 routability of EIDs. The variants are: 162 LISP 1: where EIDs are routable through the RLOC topology for 163 bootstrapping EID-to-RLOC mappings. [LISP1] 165 LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC 166 mappings; such routing is via a separate topology. 168 LISP 2: where EIDS are not routable and EID-to-RLOC mappings are 169 implemented within the DNS [LISP2] 171 LISP 3: where non-routable EIDs are used as lookup keys for a new 172 EID-to-RLOC mapping database. Use of Distributed Hash Tables 173 (DHTs) to implement such a database would be an area to explore. 174 [DHTs] 176 This document will focus on LISP 1 and LISP 1.5, both of which rely 177 on a router-based distributed cache and database for EID-to-RLOC 178 mappings. The LISP 2 and LISP 3 mechanisms, which require separate 179 EID-to-RLOC infrastructure, will be documented in additional drafts. 181 3. Definition of Terms 183 Provider Independent (PI) Addresses: an address block assigned from 184 a pool that is not associated with any service provider and is 185 therefore not topologically-aggregatable in the routing system. 187 Provider Assigned (PA) Addresses: a block of IP addresses that are 188 assigned to a site by each service provider to which a site 189 connects. Typically, each block is sub-block of a service 190 provider CIDR block and is aggregated into the larger block before 191 being advertised into the global Internet. Traditionally, IP 192 multihoming has been implemented by each multi-homed site 193 acquiring its own, globally-visible prefix. LISP uses only 194 topologically-assigned and aggregatable address blocks for RLOCs, 195 eliminating this demonstrably non-scalable practice. 197 Routing Locator (RLOC): the IP address of an egress tunnel router 198 (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID 199 maps to one or more RLOCs. Typically, RLOCs are numbered from 200 topologically-aggregatable blocks that are assigned to a site at 201 each point to which it attaches to the global Internet; where the 202 topology is defined by the connectivity of provider networks, 203 RLOCs can be thought of as PA addresses. 205 Endpoint ID (EID): a 32- or 128-bit value used in the source and 206 destination address fields of the first (most inner) LISP header 207 of a packet. The host obtains a destination EID the same way it 208 obtains an address today, typically through a DNS lookup. The 209 source EID is obtained via existing mechanisms used to set a hosts 210 "local" IP address. LISP uses PI blocks for EIDs; such EIDs MUST 211 NOT be used as a LISP RLOCs. Note that EID blocks may be assigned 212 in a hierarchical manner, independent of the network topology, to 213 facilitate scaling of the mapping database. In addition, an EID 214 block assigned to a site may have site-local structure 215 (subnetting) for routing within the site; this structure is not 216 visible to the global routing system. 218 End-system: is an IP device that originates packets with a single 219 IP header. The end-system supplies an EID value for the 220 destination address field of the IP header when communicating 221 globally (i.e. outside of it's routing domain). An end-system can 222 be a host computer, a switch or router device, or any network 223 appliance. An iPhone. 225 Ingress Tunnel Router (ITR): a router which accepts an IP packet 226 with a single IP header (more precisely, an IP packet that does 227 not contain a LISP header). The router treats this "inner" IP 228 destination address as an EID and performs an EID-to-RLOC mapping 229 lookup. The router then prepends an "outer" IP header with one of 230 its globally-routable RLOCs in the source address field and the 231 result of the mapping lookup in the destination address field. 232 Note that this destination RLOC may be an intermediate, proxy 233 device that has better knowledge of the EID-to-RLOC mapping 234 closest to the destination EID. In general, an ITR receives IP 235 packets from site end-systems on one side and sends LISP- 236 encapsulated IP packets toward the Internet on the other side. 238 Specifically, when a service provider prepends a LISP header for 239 Traffic Engineering purposes, the router that does this is also 240 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 241 on the outer destination address (the originating ITR's supplied 242 RLOC) or the inner destination address (the originating hosts 243 supplied EID). 245 Egress Tunnel Router (ETR): a router that accepts an IP packet 246 where destination address in the "outer" IP header is one of its 247 own RLOCs. The router strips the "outer" header and forwards the 248 packet based on the next IP header found. In general, an ETR 249 receives LISP-encapsulated IP packets from the Internet on one 250 side and sends decapsulated IP packets to site end-systems on the 251 other side. 253 EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that 254 stores, tracks, and is responsible for timing-out and otherwise 255 validating EID-to-RLOC mappings. This cache is distinct from the 256 "database", the cache is dynamic, local, and relatively small 257 while and the database is distributed, relatively static, and much 258 global in scope. 260 EID-to-RLOC Database: a globally, distributed database that 261 contains all known EID to RLOC mappings. Each potential ETR 262 typically contains a small piece of the database: the EID-to-RLOC 263 mappings for the EIDs "behind" the router. These map to one of 264 the router's own, globally-visible, IP addresses. This block of 265 EIDs which map to a particular RLOC is described as an "EID 266 prefix". Pieces of the database may also be aggregated and may be 267 contained in other routers that "proxy" reply for ETRs. 269 Recursive Tunneling: when a packet has more than one LISP IP 270 header. Additional layers of tunneling may be employed to 271 implement traffic engineering or other re-routing as needed. When 272 this is done, an additional "outer" LISP header is added and the 273 original RLOCs are preserved in the "inner" header. 275 Reencapsulating Tunnels: when a packet has no more than one LISP IP 276 header (two IP headers total) and when it needs to be diverted to 277 new RLOC, an ETR can decapsulate the packet (remove the LISP 278 header) and prepend a new tunnel header, with new RLOC, on to the 279 packet. Doing this allows a packet to be re-routed by the re- 280 encapsulating router without adding the overhead of additional 281 tunnel headers. 283 LISP Header: a term used in this document to refer to the outer IP 284 header an ITR prepends or an ETR strips. 286 4. Basic Overview 288 One key concept of LISP is that end-systems (hosts) operate the same 289 way they do today. The IP addresses that hosts use for tracking 290 sockets, connections, and for sending and receiving packets do not 291 change. In LISP terminology, these IP addresses are called Endpoint 292 Identifiers (EIDs). 294 Routers continue to forward packets based on IP destination 295 addresses. These addresses are referred to as Routing Locators 296 (RLOCs). Most routers along a path between two hosts will not 297 change; they continue to perform routing/forwarding lookups on 298 addresses (RLOCs) in the IP header. 300 This design introduces "Tunnel Routers", which prepend LISP headers 301 on host-originated packets and strip them prior to final delivery to 302 their destination. The IP addresses in this "outer header" are 303 RLOCs. During end-to-end packet exchange between two Internet hosts, 304 an ITR prepends a new LISP header to each packet and an egress tunnel 305 router strips the new header. The ITR performs EID-to-RLOC lookups 306 to determine the routing path to the the ETR, which has the RLOC as 307 one of its IP addresses. 309 Some basic rules governing LISP are: 311 o End-systems (hosts) only know about EIDs. 313 o EIDs are always IP addresses assigned to hosts. 315 o Routers mostly deal with Routing Locator addresses. See details 316 later in Section 4.1 to clarify what is meant by "mostly". 318 o RLOCs are always IP addresses assigned to routers; preferably, 319 topologically-oriented addresses from provider CIDR blocks. 321 o Routers can use their RLOCs as EIDs but can also be assigned EIDs 322 when performing host functions. Those EIDs MUST NOT be used as 323 RLOCs. 325 o EIDs are not expected to be usable for end-to-end communication in 326 the absence of an EID-to-RLOC mapping operation. 328 o EID prefixes are likely to be hierarchically assigned in a manner 329 which is optimized for administrative convenience and to 330 facilitate scaling of the EID-to-RLOC mapping database. 332 o EIDs may also be structured (subnetted) in a manner suitable for 333 local routing within an autonomous system. 335 An additional LISP header may be pre-pended to packets by a transit 336 router when re-routing of the end-to-end path for a packet is 337 desired. An obvious instance of this would be an ISP router that 338 needs to perform traffic engineering for packets in flow through its 339 network. In such a situation, termed Recursive Tunneling, an ISP 340 transit acts as an additional ingress tunnel router and the RLOC it 341 uses for the new prepended header would be either an ETR within the 342 ISP (along intra-ISP traffic engineered path) or in an ETR within 343 another ISP (an inter-ISP traffic engineered path, where an agreement 344 to build such a path exists). 346 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 347 For example, the ITR for a particular end-to-end packet exchange 348 might be the first-hop or default router within a site for the source 349 host. Similarly, the egress tunnel router might be the last-hop 350 router directly-connected to the destination host. Another example, 351 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 352 could be the site's border router at the service provider attachment 353 point. Mixing and matching of site-operated, ISP-operated, and other 354 tunnel routers is allowed for maximum flexibility. See Section 8 for 355 more details. 357 4.1. Packet Flow Sequence 359 This section provides an example of the unicast unicast packet flow 360 with the following parameters: 362 o Source host "host1.abc.com" is sending a packet to 363 "host2.xyz.com". 365 o Each site is multi-homed, so each tunnel router has an address 366 (RLOC) assigned from each of the site's attached service provider 367 address blocks. 369 o The ITR and ETR are directly connected to the source and 370 destination, respectively. 372 Client host1.abc.com wants to communicate with server host2.xyz.com: 374 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 375 It does a DNS lookup on host2.xyz.com. An A record is returned. 376 This address is used as the destination EID and the locally- 377 assigned address of host1.abc.com is used as the source EID. An 378 IP packet is built using the EIDs in the IP header and sent to 379 the default router. 381 2. The default router is configured as an ITR. It prepends a LISP 382 header to the packet, with one of it's RLOCs as the source IP 383 address and uses the destination EID from the original packet 384 header as the destination IP address. 386 3. In LISP 1, the packet is routed through the Internet as it is 387 today. In LISP 1.5, the packet is routed on a different topology 388 which may have EID prefixes distributed and advertised in an 389 aggregatable fashion. In either case, the packet arrives at the 390 ETR. The router is configured to "punt" the packet to the 391 router's control-plane processor. See Section 7 for more 392 details. 394 4. The LISP header is stripped so that the packet can be forwarded 395 by the router control-plane. The router looks up the destination 396 EID in the router's EID-to-RLOC database (not the cache, but the 397 configured data structure of RLOCs). An ICMP EID-to-RLOC Mapping 398 message is originated by the egress router and is addressed to 399 the source RLOC from the LISP header of the original packet (this 400 is the ITR). The source RLOC in the IP header of the ICMP 401 message is one of the ETR's RLOCs (one of the RLOCs that is 402 embedded in the ICMP payload). 404 5. The ITR receives the ICMP message, parses the message (to check 405 for format validity) and stores the EID-to-RLOC information from 406 the packet. This information is put in the ITR's EID-to-RLOC 407 mapping cache (this is the on-demand cache, the cache where 408 entries time out due to inactivity). 410 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 411 a LISP header prepended with the RLOCs learned from the ETR. 413 7. The egress tunnel receives these packets directly (since the 414 destination address is one of its assigned IP addresses), strips 415 the LISP header and delivers the packets to the attached 416 destination host. 418 In order to eliminate the need for a mapping lookup in the reverse 419 direction, the ETR gleans RLOC information from the LISP header. 420 Both ITR and the ETR may also influence the decision the other makes 421 in selecting an RLOC. See section Section 6 for more details. 423 5. Tunneling Details 425 This section describes the tunnel header details. LISP uses the 426 existing, IP-in-IP encapsulation as described below. 428 LISP IP-in-IP header format 430 0 1 2 3 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 / |Version| IHL |Type of Service| Total Length | 434 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 / | Identification |Flags| Fragment Offset | 436 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 OH | Time to Live | Protocol = 4 | Header Checksum | 438 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 \ | Source Routing Locator | 440 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 \ | Destination Routing Locator | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 / |Version| IHL |Type of Service| Total Length | 444 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 / | Identification |Flags| Fragment Offset | 446 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 IH | Time to Live | Protocol | Header Checksum | 448 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 \ | Source EID | 450 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 \ | Destination EID | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Header IH is the inner header, preserved from the datagram received 455 from the originating host. The source and destination IP addresses 456 are EIDs. 458 Header OH is the outer header prepended by an ITR. The address 459 fields contain RLOCs obtained from the ingress router's EID-to-RLOC 460 cache. The IP protocol number is "IP in IP encapsulation" from 461 [RFC2003]. 463 When doing Recursive Tunneling: 465 o The OH header Time to Live field SHOULD be copied from the IH 466 header Time to Live field. 468 o The OH header Type of Service field SHOULD be copied from the IH 469 header Type of Service field. 471 When doing Re-encapsulated Tunneling: 473 o The new OH header Time to Live field SHOULD be copied from the 474 stripped OH header Time to Live field. 476 o The new OH header Type of Service field SHOULD be copied from the 477 stripped OH header Type of Service field. 479 6. EID-to-RLOC Mapping 481 6.1. Control-Plane Packet Format 483 When LISP 1 or LISP 1.5 are used, a new ICMP packet type encodes the 484 EID-to-RLOC mappings: 486 0 1 2 3 487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |Version| IHL |Type of Service| Total Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Identification |Flags| Fragment Offset | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Time to Live | Protocol = 1 | Header Checksum | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Source Routing Locator | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Destination Routing Locator | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type = 42 | Code | Checksum | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Record Count | Unused | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | RLOC Count | EID Mask Len | EID Prefix 1 ... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Priority | Weight | Routing Locator 1 ... | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | . . . | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Priority | Weight | Routing Locator n ... | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | . . . | 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Locator Count | EID Mask Len | EID Prefix n ... | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Priority | Weight | Routing Locator 1 ... | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | . . . | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Priority | Weight | Routing Locator n ... | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Packet field descriptions: 527 ICMP Type - set to 42 for an "EID-to-RLOC Mapping" message. 529 ICMP Code - 1 is a Request, 2 is a Reply. 531 ICMP Checksum - 1's complement checksum of the entire ICMP packet. 533 Unused - transmitted as 0 and ignored on receipt. 535 Record Count - unassigned number of records contained in the 536 message. A record contains a mapping of an EID-prefix to a set of 537 RLOCs. A record count of 0 is illegal. 539 RLOC Count - The number of RLOCs associated with this EID prefix. 541 EID Mask Len - The mask length of the EID prefix. By encoding an 542 EID prefix, a set of RLOCs can be associated with a block of EIDs. 543 Values are between 0 and 32 inclusive. 545 EID Prefix - the encoded EID, represented as an IP address. This 546 field is 4 bytes in length. 548 Priority - each RLOC is assigned a priority. Lower values are more 549 preferable. When multiple RLOCs have the same priority, they are 550 used in a load-split fashion. A value of 255 means the RLOC 551 should not be used. 553 Weight - when priorities are the same for multiple RLOCs, the 554 weight indicates how to balance traffic between them. Weight is 555 encoded as a percentage. If a non-zero weight value is used for 556 any RLOC, then all RLOCs must use a non-zero weight value and then 557 the sum of all weight values MUST equal 100. Going to buy an 558 iPhone? If a zero value is used for any RLOC weight, then all 559 weights must be zero and the receiver of the Reply will decide how 560 to load-split traffic. 562 Routing Locator (RLOC) - an IP address assigned to an ETR or router 563 acting as a proxy replier for the EID-prefix. Note that the RLOC 564 address can be an anycast address if the tunnel egress point may 565 be via more than one physical device. The source or destination 566 RLOC MUST NEVER be the broadcast address (255.255.255.255). The 567 source RLOC MUST NEVER be a multicast address. The destination 568 RLOC SHOULD be a multicast address if it is being mapped from a 569 multicast destination EID. 571 6.1.1. EID-to-RLOC Mapping Request Message 573 A Request contains one or more EIDs encoded in prefix format with a 574 Locator count of 0. The EID-prefix should be no more specific than a 575 cache entry stored from a previously-received Reply. 577 A request is sent from an ITR when it wants to test an RLOC for 578 reachability. This testing is performed by using the RLOC as the 579 destination address for type of ICMP packet. A successful reply 580 updates the cached set of RLOCs associated with the EID prefix range. 582 Requests MUST be rate-limited. It is recommended that a Request for 583 the same EID-prefix be sent no more than once per second. 585 6.1.2. EID-to-RLOC Mapping Reply Message 587 When a data packet triggers a Reply to be sent, the RLOC associated 588 with the EID-prefix matched by the EID in the original packet 589 destination IP address field will be returned. The RLOCs in the 590 Reply are the globally-routable IP addresses of the ETR but are not 591 necessarily reachable; separate testing of reachability is required. 593 Note that a Reply may contain different EID-prefix granularity 594 (prefix + length) than the Request which triggers it. This might 595 occur if a Request were for a prefix that had been returned by an 596 earlier Reply. In such a case, the requester updates its cache with 597 the new prefix information and granularity. For example, a requester 598 with two cached EID-prefixes that are covered by a Reply containing 599 one, less-specific prefix, replaces the entry with the less-specific 600 EID-prefix. Note that the reverse, replacement of one less-specific 601 prefix with multiple more-specific prefixes, can also occur but not 602 by removing the less-specific prefix rather by adding the more- 603 specific prefixes which during a lookup will override the less- 604 specific prefix. 606 Replies should be sent for an EID-prefix no more often than once per 607 second to the same requesting router. For scalability, it is 608 expected that aggregation of blocks of EIDs into EID-prefixes will 609 allow one Reply to suppress further Requests for multiple EIDs in the 610 EID-prefix range. 612 6.2. Routing Locator Selection and Reachability 614 Both client-side and server-side may need control over the selection 615 RLOCs for conversations between them. This control is achieved by 616 manipulating the Priority and Weight fields in ICMP EID-to-RLOC 617 Mapping Reply messages. Alternatively, RLOC information may be 618 gleaned from received tunneled packets or ICMP EID-to-RLOC Mapping 619 Request messages. 621 The following enumerates different scenarios for choosing RLOCs and 622 the controls that are available: 624 o Server-side returns one RLOC. Client-side can only use one RLOC. 625 Server-side has complete control of the selection. 627 o Server-side returns a list of RLOC where a subset of the list has 628 the same best priority. Client can only use the subset list 629 according to the weighting assigned by the server-side. In this 630 case, the server-side controls both the subset list and load- 631 splitting across its members. The client-side can use RLOCs 632 outside of the subset list if it determines that the subset list 633 is unreachable (unless RLOCs are set to a Priority of 255). Some 634 sharing of control exists: the server-side determines the 635 destination RLOC list and load distribution while the client-side 636 has the option of using alternatives to this list if RLOCs in the 637 list are unreachable. 639 o Server-side sets weight of 0 for the RLOC subset list. In this 640 case, the client-side can choose how the traffic load is spread 641 across the subset list. Control is shared by the server-side 642 determining the list and the client determining load distribution. 643 Again, the client can use alternative RLOCs if the server-provided 644 list of RLOCs are unreachable. 646 o Either side (more likely on the server-side) decides not send an 647 ICMP EID-to-RLOC Mapping Request. For example, if the server-side 648 does not send Requests, it gleans RLOCs from the client-side, 649 giving the client-side responsibility for bidirectional RLOC 650 reachability and preferability. Server-side gleaning of the 651 client-side RLOC is done by caching the inner header source EID 652 and the outer header source RLOC of received packets. The client- 653 side controls how traffic is returned and can alternate using an 654 outer header source RLOC, which then can be added to the list the 655 server-side uses to return traffic. Since no Priority or Weights 656 are provided using this method, the server-side must assume each 657 client-side RLOC uses the same best Priority with a Weight of 658 zero. In addition, since EID-prefix encoding cannot be conveyed 659 in data packets, the EID-to-RLOC cache on tunnel routers can grow 660 to be very large. 662 An RLOC in the list returned by a EID-to-RLOC Mapping Reply is only 663 known to be reachable when an EID-to-RLOC Mapping Request sent using 664 it as the destination IP address results in the a successful reply 665 containing it as a source IP address. Obviously, sending such probes 666 increases the number of control messages originated by tunnel routers 667 for active flows, so RLOC as assumed to be reachable when they are 668 advertised. 670 This assumption does create a dependency: RLOC unreachability is 671 detected by the receipt of ICMP Host Unreachable messages. When an 672 RLOC has been determined unreachable, it is not used for active 673 traffic; this is the same as if it is listed in a Mapping Reply with 674 priority 255. 676 The ITR can later test the reachability of the unreachable RLOC by 677 sending periodic Requests. Both Requests and Replies MUST be rate- 678 limited. RLOC reachability testing is never done with data packets 679 since that increases the risk of packet loss for end-to-end sessions. 681 7. Router Performance Considerations 683 LISP is designed to be very hardware-based forwarding friendly. By 684 doing tunnel header prepending [RFC1955] and stripping instead of re- 685 writing addresses, existing hardware can support the forwarding model 686 with little or no modification. Where modifications are required, 687 they should be limited to re-programming existing hardware rather 688 than requiring expensive design changes to hard-coded algorithms in 689 silicon. 691 A few implementation techniques can be used to incrementally 692 implement LISP: 694 o When a tunnel encapsulated packet is received by an ETR, the outer 695 destination address may not be the address of the router. This 696 makes it challenging for the control-plane to get packets from the 697 hardware. This may be mitigated by creating special FIB entries 698 for the EID-prefixes of EIDs served by the ETR (those for which 699 the router provides an RLOC translation). These FIB entries are 700 marked with a flag indicating that control-plane processing should 701 be performed. The forwarding logic of testing for particular IP 702 protocol number value is not necessary. No changes to existing, 703 deployed hardware should be needed to support this. 705 o On an ITR, prepending a new IP header is as simple as adding more 706 bytes to a MAC rewrite string and prepending the string as part of 707 the outgoing encapsulation procedure. Many routers that support 708 GRE tunneling or 6to4 tunneling can already support this action. 710 o When a received packet's outer destination address contains an EID 711 which is not intended to be forwarded on the routable topology 712 (i.e. LISP 1.5), the source address of a data packet or the 713 router interface with which the source is associated (the 714 interface from which is was received) can be associated with a 715 VRF, in which a different (i.e. non-congruent) topology can be 716 used to find EID-to-RLOC mappings. 718 8. Deployment Scenarios 720 This section will explore how and where ingress and ETRs can be 721 deployed and will discuss the pros and cons of each deployment 722 scenario. There are two basic deployment tradeoffs to consider: 723 centralized versus distributed caches and flat, recursive, or re- 724 encapsulating tunneling. 726 When deciding on centralized versus distributed caching, the 727 following issues should be considered: 729 o Are the tunnel routers spread out so that the caches are spread 730 across all the memories of each router? 732 o Should management "touch points" be minimized by choosing few 733 tunnel routers, just enough for redundancy? 735 o In general, using more ITRs doesn't increase management load, 736 since caches are built and stored dynamically. On the other hand, 737 more ETRs does require more management since EID-prefix-to-Locator 738 mappings need to be explicitly configured. 740 When deciding on flat, recursive, or re-encapsulation tunneling, the 741 following issues should be considered: 743 o Flat tunneling implements a single tunnel between source site and 744 destination site. This generally offers better paths between 745 sources and destinations with a single tunnel path. 747 o Recursive tunneling is when tunneled traffic is again further 748 encapsulated in another tunnel, either to implement VPNs or to 749 perform Traffic Engineering. When doing VPN-based tunneling, the 750 site has some control since the site is prepending a new tunnel 751 header. In the case of TE-based tunneling, the site may have 752 control if it is prepending a new tunnel header, but if the site's 753 ISP is doing the TE, then the site has no control. Recursive 754 tunneling generally will result in suboptimal paths but at the 755 benefit of steering traffic to resource available parts of the 756 network. 758 o The technique of re-encapsulation ensures that packets only 759 require one tunnel header. So if a packet needs to be rerouted, 760 it is first decapsulated by the ETR and then re-encapsulated with 761 a new tunnel header using a new RLOC. 763 The next sub-sections will describe where tunnel routers can reside 764 in the network. 766 8.1. First-hop/Last-hop Tunnel Routers 768 By locating tunnel routers close to hosts, the EID-prefix set is at 769 the granularity of an IP subnet. So at the expense of more EID- 770 prefix-to-Locator sets for the site, the caches in each tunnel router 771 can remain relatively small. But caches always depend on the number 772 of non-aggregated EID destination flows active through these tunnel 773 routers. 775 With more tunnel routers doing encapsulation, the increase in control 776 traffic grows as well: since the EID-granularity is greater, more 777 requests and replies are traveling between more routers. 779 The advantage of placing the caches and databases at these stub 780 routers is that the products deployed in this part of the network 781 have better price-memory ratios then their core router counterparts. 782 Memory is typically less expensive in these devices and fewer routes 783 are stored (only IGP routes). These devices tend to have excess 784 capacity, both for forwarding and routing state. 786 LISP functionality can be also deployed in edge switches. These 787 devices generally have layer-2 facing hosts and layer-3 ports facing 788 the Internet. Spare capacity is also often available in these 789 devices as well. 791 8.2. Border/Edge Tunnel Routers 793 Using customer-edge (CE) routers for tunnel endpoints allows the EID 794 space associated with a site to be reachable via a small set of RLOCs 795 assigned to the CE routers for that site. 797 This offers the opposite benefit of the first-hop/last-hop tunnel 798 router scenario: the number of mapping entries and network management 799 touch points are reduced, allowing better scaling. 801 One disadvantage is that less of the network's resources are used to 802 reach host endpoints thereby centralizing the point-of-failure domain 803 and creating network choke points at the CE router. 805 8.3. ISP Provider-Edge (PE) Tunnel Routers 807 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 808 over the location of the egress tunnel endpoints. That is, the ISP 809 can decide if the tunnel endpoints are in the destination site (in 810 either CE routers or last-hop routers within a site) or at other PE 811 edges. The advantage of this case is that two or more tunnel headers 812 can be avoided. By having the PE be the first router on the path to 813 encapsulate, it can choose a TE path first, and the ETR can 814 decapsulate and re-encapsulate for a tunnel to the destination end 815 site. 817 An obvious disadvantage is that the end site has no control over 818 where its packets flow or the RLOCs used. 820 As mentioned in earlier sections a combination of these scenarios is 821 possible at the expense of extra packet header overhead, if both site 822 and provider want control, then recursive or re-encapsulating tunnels 823 are used. 825 9. Multicast Considerations 827 A multicast group address, as defined in the original Internet 828 architecture is an identifier of a grouping of topologically 829 independent receiver host locations. The address encoding itself 830 does not determine the location of the receiver(s). The multicast 831 routing protocol, and the network-based state the protocol creates, 832 determines where the receivers are located. 834 In the context of LISP, a multicast group address is both an EID and 835 a Routing Locator. Therefore, no specific semantic or action needs 836 to be taken for a destination address, as it would appear in an IP 837 header. Therefore, a group address that appears in an inner IP 838 header (the destination EID) built by a source host will be used as 839 the destination EID. And the outer IP header (the destination 840 Routing Locator address), prepended by a LISP router, will use the 841 same group address as the destination Routing Locator. 843 Having said that, only the source EID and source Routing Locator 844 needs to be dealt with. Therefore, an ITR merely needs to put its 845 own IP address in the source Routing Locator field when prepending 846 the outer IP header. This source Routing Locator address, like any 847 other Routing Locator address must be globally routable. 849 Therefore, an EID-to-RLOC mapping does not need to be performed by an 850 ITR when a received data packet is a multicast data packet. But the 851 source Routing Locator is decided by the multicast routing protocol 852 in a receiver site. That is, an EID to Routing Locator translation 853 is done at control-time. 855 10. Security Considerations 857 ICMP EID-to-RLOC Reply messages are authoritative to the same extent 858 DNS Replies are. LISP is no less secure than DNS and at this time we 859 do not intend to add any additional security mechanisms to the 860 proposal. 862 However, in future versions of this draft, we will add cryptographic 863 authenticity to ICMP EID-to-RLOC messages. 865 11. Prototype Plans 867 The operator community has requested that the IETF take a practical 868 approach to solving the scaling problems associated with global 869 routing state growth. This document offers a simple solution which 870 is intended for use in a pilot program to gain experience in working 871 on this problem. 873 The authors hope that publishing this specification will allow the 874 rapid implementation of multiple vendor prototypes and deployment on 875 a small scale. Doing this will help the community: 877 o Decide whether a new EID-to-RLOC mapping database infrastructure 878 is needed or if a simple, ICMP-based, data-triggered approach is 879 flexible and robust enough. 881 o Experiment with provider-independent assignment of EIDs while at 882 the same time decreasing the size of DFZ routing tables through 883 the use of topologically-aligned, provider-based RLOCs. 885 o Determine whether multiple levels of tunneling can be used by ISPs 886 to achieve their Traffic Engineering goals while simultaneously 887 removing the more specific routes currently injected into the 888 global routing system for this purpose. 890 o Experiment with mobility to determine if both acceptable 891 convergence and session survivability properties can be scalably 892 implemented to support both individual device roaming and site 893 service provider changes. 895 Here are a rough set of milestones: 897 1. Stabilize this draft by Spring 2007 Prague IETF. 899 2. Start implementation to report on by Spring 2007 Prague IETF. 901 3. Start pilot deployment between spring and summer IETFs. Report 902 on deployment at Summer 2007 Chicago IETF. 904 4. Achieve multi-vendor interoperability by Summer 2007 Chicago 905 IETF. 907 5. Consider prototyping other database lookup schemes, be it DNS, 908 DHTs, or other mechanisms by Fall 2007 IETF. 910 12. References 912 12.1. Normative References 914 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 915 Destinations", RFC 1498, August 1993. 917 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 918 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 920 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 921 October 1996. 923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 924 Requirement Levels", BCP 14, RFC 2119, March 1997. 926 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 927 (HIP) Architecture", RFC 4423, May 2006. 929 12.2. Informative References 931 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 932 Enhancement to the Internet Architecture", Internet- 933 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 934 1999. 936 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 937 Algorithms for DHTs: Some Open Questions", PDF 938 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 940 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 941 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 943 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 944 "Locator/ID Separation Protocol (LISP1) [Routable ID 945 Version]", 946 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 947 October 2006. 949 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 950 "Locator/ID Separation Protocol (LISP2) [DNS-based 951 Version]", 952 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 953 November 2006. 955 [RAWS] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 956 Workshop on Routing and Addressing", 957 draft-iab-raws-report-00.txt (work in progress), 958 November 2006. 960 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 961 protocol", draft-ietf-shim6-proto-06.txt (work in 962 progress), October 2006. 964 Appendix A. Acknowledgments 966 The authors would like to gratefully acknowledge many people who have 967 contributed discussion and ideas to the making of this proposal. 968 They include Dave Meyer, Jason Schiller, Lixia Zhang, Dorian Kim, 969 Peter Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David 970 Conrad, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian 971 Weis, and Dave McGrew. 973 In particular, we would like to thank Dave Meyer for his clever 974 suggestion for the name "LISP". ;-) 976 Authors' Addresses 978 Dino Farinacci 979 cisco Systems 980 Tasman Drive 981 San Jose, CA 95134 982 USA 984 Email: dino@cisco.com 986 Vince Fuller 987 cisco Systems 988 Tasman Drive 989 San Jose, CA 95134 990 USA 992 Email: vaf@cisco.com 994 Dave Oran 995 cisco Systems 996 7 Ladyslipper Lane 997 Acton, MA 998 USA 1000 Email: oran@cisco.com 1002 Full Copyright Statement 1004 Copyright (C) The Internet Society (2007). 1006 This document is subject to the rights, licenses and restrictions 1007 contained in BCP 78, and except as set forth therein, the authors 1008 retain all their rights. 1010 This document and the information contained herein are provided on an 1011 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1012 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1013 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1014 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1015 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1016 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1018 Intellectual Property 1020 The IETF takes no position regarding the validity or scope of any 1021 Intellectual Property Rights or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; nor does it represent that it has 1025 made any independent effort to identify any such rights. Information 1026 on the procedures with respect to rights in RFC documents can be 1027 found in BCP 78 and BCP 79. 1029 Copies of IPR disclosures made to the IETF Secretariat and any 1030 assurances of licenses to be made available, or the result of an 1031 attempt made to obtain a general license or permission for the use of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository at 1034 http://www.ietf.org/ipr. 1036 The IETF invites any interested party to bring to its attention any 1037 copyrights, patents or patent applications, or other proprietary 1038 rights that may cover technology that may be required to implement 1039 this standard. Please address the information to the IETF at 1040 ietf-ipr@ietf.org. 1042 Acknowledgment 1044 Funding for the RFC Editor function is provided by the IETF 1045 Administrative Support Activity (IASA).