idnits 2.17.1 draft-farinacci-lisp-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1482. 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 IETF Trust 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 (August 13, 2007) is 6099 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-01) exists of draft-jen-apt-00 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-01 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-01 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-03 -- No information found for draft-handley-p2ppush-unpublished-2007726 - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-06 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 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: February 14, 2008 D. Meyer 6 cisco Systems 7 August 13, 2007 9 Locator/ID Separation Protocol (LISP) 10 draft-farinacci-lisp-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 14, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This draft describes a simple, incremental, network-based protocol to 44 implement separation of Internet addresses into Endpoint Identifiers 45 (EIDs) and Routing Locators (RLOCs). This mechanism requires no 46 changes to host stacks and no major changes to existing database 47 infrastructures. The proposed protocol can be implemented in a 48 relatively small number of routers. 50 This proposal was stimulated by the problem statement effort at the 51 Amsterdam IAB Routing and Addressing Workshop (RAWS), which took 52 place in October 2006. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 59 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 10 61 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 13 62 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 63 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 64 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 16 65 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 18 66 6.1. Control-Plane Packet Format . . . . . . . . . . . . . . . 18 67 6.1.1. Map-Request Message Format . . . . . . . . . . . . . . 20 68 6.1.2. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 21 69 6.1.3. Map-Reply Message Format . . . . . . . . . . . . . . . 22 70 6.1.4. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 24 71 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 24 72 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 26 73 7. Router Performance Considerations . . . . . . . . . . . . . . 28 74 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 29 75 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 30 76 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 30 77 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 31 78 9. Multicast Considerations . . . . . . . . . . . . . . . . . . . 32 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 80 11. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 34 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 36 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 86 Intellectual Property and Copyright Statements . . . . . . . . . . 40 88 1. Requirements Notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 Many years of discussion about the current IP routing and addressing 97 architecture have noted that its use of a single numbering space (the 98 "IP address") for both host transport session identification and 99 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 100 A number of scaling benefits would be realized by separating the 101 current IP address into separate spaces for Endpoint Identifiers 102 (EIDs) and Routing Locators (RLOCs); among them are: 104 1. Reduction of routing table size in the "default-free zone" (DFZ). 105 Use of a separate numbering space for RLOCs will allow them to be 106 assigned topologically (in today's Internet, RLOCs would be 107 assigned by providers at client network attachment points), 108 greatly improving aggregation and reducing the number of 109 globally-visible, routable prefixes. 111 2. Easing of renumbering burden when clients change providers. 112 Because host EIDs are numbered from a separate, non-provider- 113 assigned and non-topologically-bound space, they do not need to 114 be renumbered when a client site changes its attachment points to 115 the network. 117 3. Mobility with session survivability. Because session state is 118 associated with a persistent host EID, it should be possible for 119 a host (or a collection of hosts) to move to a different point in 120 the network topology (whether by changing providers or by 121 physically moving) without disruption of connectivity. 123 4. Traffic engineering capabilities that can be performed by network 124 elements and do not depend on injecting additional state into the 125 routing system. This will fall out of the mechanism that is used 126 to implement the EID/RLOC split (see Section 4). 128 This draft describes protocol mechanisms to achieve the desired 129 functional separation. For flexibility, the document decouples the 130 mechanism used for forwarding packets from that used to determine EID 131 to RLOC mappings. This work is in response to and intended to 132 address the problem statement that came out of the RAWS effort 133 [RAWS]. 135 This draft focuses on a router-based solution. Building the solution 136 into the network should facilitate incremental deployment of the 137 technology on the Internet. Note that while the detailed protocol 138 specification and examples in this document assume IP version 4 139 (IPv4), there is nothing in the design that precludes use of the same 140 techniques and mechanisms for IPv6. It should be possible for IPv4 141 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 142 RLOCs. 144 Related work on host-based solutions is described in Shim6 [SHIM6] 145 and HIP [RFC4423]. Related work on other router-based solutons is 146 described in GSE [GSE]. This draft attempts to not compete or 147 overlap with such solutions and the proposed protocol changes are 148 expected to complement a host-based mechanism when Traffic 149 Engineering functionality is desired. 151 Some of the design goals of this proposal include: 153 1. Minimize required changes to Internet infrastructure. 155 2. Require no hardware or software changes to end-systems (hosts). 157 3. Be incrementally deployable. 159 4. Require no router hardware changes. 161 5. Minimize router software changes. 163 6. Avoid or minimize packet loss when EID-to-RLOC mappings need to 164 be performed. 166 There are 4 variants of LISP, which differ along a spectrum of strong 167 to weak dependence on the topological nature and possible need for 168 routability of EIDs. The variants are: 170 LISP 1: where EIDs are routable through the RLOC topology for 171 bootstrapping EID-to-RLOC mappings. [LISP1] 173 LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC 174 mappings; such routing is via a separate topology. 176 LISP 2: where EIDS are not routable and EID-to-RLOC mappings are 177 implemented within the DNS. [LISP2] 179 LISP 3: where non-routable EIDs are used as lookup keys for a new 180 EID-to-RLOC mapping database. Use of Distributed Hash Tables 181 [DHTs] to implement such a database would be an area to explore. 182 Other examples of new mapping database services are [CONS], 183 [RPMD], [NERD], and [APT]. 185 This document will focus on LISP 1 and LISP 1.5, both of which rely 186 on a router-based distributed cache and database for EID-to-RLOC 187 mappings. The LISP 2 and LISP 3 mechanisms, which require separate 188 EID-to-RLOC infrastructure, will be documented in additional drafts. 190 3. Definition of Terms 192 Provider Independent (PI) Addresses: an address block assigned from 193 a pool that is not associated with any service provider and is 194 therefore not topologically-aggregatable in the routing system. 196 Provider Assigned (PA) Addresses: a block of IP addresses that are 197 assigned to a site by each service provider to which a site 198 connects. Typically, each block is sub-block of a service 199 provider CIDR block and is aggregated into the larger block before 200 being advertised into the global Internet. Traditionally, IP 201 multihoming has been implemented by each multi-homed site 202 acquiring its own, globally-visible prefix. LISP uses only 203 topologically-assigned and aggregatable address blocks for RLOCs, 204 eliminating this demonstrably non-scalable practice. 206 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 207 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 208 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 209 numbered from topologically-aggregatable blocks that are assigned 210 to a site at each point to which it attaches to the global 211 Internet; where the topology is defined by the connectivity of 212 provider networks, RLOCs can be thought of as PA addresses. 213 Multiple RLOCs can be assigned to the same ETR device or to 214 multiple ETR devices at a site. 216 Endpoint ID (EID): a 32- or 128-bit value used in the source and 217 destination address fields of the first (most inner) LISP header 218 of a packet. The host obtains a destination EID the same way it 219 obtains an destination address today, for example through a DNS 220 lookup or SIP exchange. The source EID is obtained via existing 221 mechanisms used to set a hosts "local" IP address. An EID is 222 allocated to a host from an EID-prefix block associated with the 223 site the host is attached to. An EID can be used by a host to 224 refer to other hosts. LISP uses PI blocks for EIDs; such EIDs 225 MUST NOT be used as LISP RLOCs. Note that EID blocks may be 226 assigned in a hierarchical manner, independent of the network 227 topology, to facilitate scaling of the mapping database. In 228 addition, an EID block assigned to a site may have site-local 229 structure (subnetting) for routing within the site; this structure 230 is not visible to the global routing system. 232 EID-prefix: A power-of-2 block of EIDs which are allocated to a 233 site by an address allocation authority. EID-prefixes are 234 associated with a set of RLOC addresses which make up a "database 235 mapping". EID-prefix allocations can be broken up into smaller 236 blocks when an RLOC set is to be associated with the smaller EID- 237 prefix. 239 End-system: is an IPv4 or IPv6 device that originates packets with 240 a single IPv4 or IPv6 header. The end-system supplies an EID 241 value for the destination address field of the IP header when 242 communicating globally (i.e. outside of it's routing domain). An 243 end-system can be a host computer, a switch or router device, or 244 any network appliance. An iPhone. 246 Ingress Tunnel Router (ITR): a router which accepts an IP packet 247 with a single IP header (more precisely, an IP packet that does 248 not contain a LISP header). The router treats this "inner" IP 249 destination address as an EID and performs an EID-to-RLOC mapping 250 lookup. The router then prepends an "outer" IP header with one of 251 its globally-routable RLOCs in the source address field and the 252 result of the mapping lookup in the destination address field. 253 Note that this destination RLOC may be an intermediate, proxy 254 device that has better knowledge of the EID-to-RLOC mapping 255 closest to the destination EID. In general, an ITR receives IP 256 packets from site end-systems on one side and sends LISP- 257 encapsulated IP packets toward the Internet on the other side. 259 Specifically, when a service provider prepends a LISP header for 260 Traffic Engineering purposes, the router that does this is also 261 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 262 on the outer destination address (the originating ITR's supplied 263 RLOC) or the inner destination address (the originating hosts 264 supplied EID). 266 TE-ITR: is an ITR that is deployed in a service provider network 267 that prepends an additional LISP header for Traffic Engineering 268 purposes. 270 Egress Tunnel Router (ETR): a router that accepts an IP packet 271 where destination address in the "outer" IP header is one of its 272 own RLOCs. The router strips the "outer" header and forwards the 273 packet based on the next IP header found. In general, an ETR 274 receives LISP-encapsulated IP packets from the Internet on one 275 side and sends decapsulated IP packets to site end-systems on the 276 other side. ETR functionality does not have to be limited to a 277 router device. A server host can be the endpoint of a LISP tunnel 278 as well. 280 TE-ETR: is an ETR that is deployed in a service provider network 281 that strips an outer LISP header for Traffic Engineering purposes. 283 EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that 284 stores, tracks, and is responsible for timing-out and otherwise 285 validating EID-to-RLOC mappings. This cache is distinct from the 286 "database", the cache is dynamic, local, and relatively small 287 while and the database is distributed, relatively static, and much 288 global in scope. 290 EID-to-RLOC Database: a globally, distributed database that 291 contains all known EID-prefix to RLOC mappings. Each potential 292 ETR typically contains a small piece of the database: the EID-to- 293 RLOC mappings for the EID prefixes "behind" the router. These map 294 to one of the router's own, globally-visible, IP addresses. 296 Recursive Tunneling: when a packet has more than one LISP IP 297 header. Additional layers of tunneling may be employed to 298 implement traffic engineering or other re-routing as needed. When 299 this is done, an additional "outer" LISP header is added and the 300 original RLOCs are preserved in the "inner" header. 302 Reencapsulating Tunnels: when a packet has no more than one LISP IP 303 header (two IP headers total) and when it needs to be diverted to 304 new RLOC, an ETR can decapsulate the packet (remove the LISP 305 header) and prepend a new tunnel header, with new RLOC, on to the 306 packet. Doing this allows a packet to be re-routed by the re- 307 encapsulating router without adding the overhead of additional 308 tunnel headers. 310 LISP Header: a term used in this document to refer to the outer 311 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 312 prepends or an ETR strips. 314 Address Family Indicator (AFI): a term used to describe an address 315 encoding in a packet. An address family currently pertains to an 316 IPv4 or IPv6 address. See [AFI] for details. 318 4. Basic Overview 320 One key concept of LISP is that end-systems (hosts) operate the same 321 way they do today. The IP addresses that hosts use for tracking 322 sockets, connections, and for sending and receiving packets do not 323 change. In LISP terminology, these IP addresses are called Endpoint 324 Identifiers (EIDs). 326 Routers continue to forward packets based on IP destination 327 addresses. These addresses are referred to as Routing Locators 328 (RLOCs). Most routers along a path between two hosts will not 329 change; they continue to perform routing/forwarding lookups on 330 addresses (RLOCs) in the IP header. 332 This design introduces "Tunnel Routers", which prepend LISP headers 333 on host-originated packets and strip them prior to final delivery to 334 their destination. The IP addresses in this "outer header" are 335 RLOCs. During end-to-end packet exchange between two Internet hosts, 336 an ITR prepends a new LISP header to each packet and an egress tunnel 337 router strips the new header. The ITR performs EID-to-RLOC lookups 338 to determine the routing path to the the ETR, which has the RLOC as 339 one of its IP addresses. 341 Some basic rules governing LISP are: 343 o End-systems (hosts) only know about EIDs. 345 o EIDs are always IP addresses assigned to hosts. 347 o Routers mostly deal with Routing Locator addresses. See details 348 later in Section 4.1 to clarify what is meant by "mostly". 350 o RLOCs are always IP addresses assigned to routers; preferably, 351 topologically-oriented addresses from provider CIDR blocks. 353 o Routers can use their RLOCs as EIDs but can also be assigned EIDs 354 when performing host functions. Those EIDs MUST NOT be used as 355 RLOCs. When EIDs are used the routeability of them is scoped to 356 within the site. A hybrid use of this, for example is when a 357 router runs the BGP protocol where iBGP peerings may use EIDs and 358 eBGP peerings may use RLOCs. 360 o EIDs are not expected to be usable for global end-to-end 361 communication in the absence of an EID-to-RLOC mapping operation. 362 They are expected to be used locally for intra-site communication. 364 o EID prefixes are likely to be hierarchically assigned in a manner 365 which is optimized for administrative convenience and to 366 facilitate scaling of the EID-to-RLOC mapping database. The 367 hierarchy is based on a address alocation hierarchy which is not 368 dependent on the network toplogy. 370 o EIDs may also be structured (subnetted) in a manner suitable for 371 local routing within an autonomous system. 373 An additional LISP header may be pre-pended to packets by a transit 374 router (i.e. TE-ITR) when re-routing of the end-to-end path for a 375 packet is desired. An obvious instance of this would be an ISP 376 router that needs to perform traffic engineering for packets in flow 377 through its network. In such a situation, termed Recursive 378 Tunneling, an ISP transit acts as an additional ingress tunnel router 379 and the RLOC it uses for the new prepended header would be either an 380 TE-ETR within the ISP (along intra-ISP traffic engineered path) or in 381 an TE-ETR within another ISP (an inter-ISP traffic engineered path, 382 where an agreement to build such a path exists). 384 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 385 For example, the ITR for a particular end-to-end packet exchange 386 might be the first-hop or default router within a site for the source 387 host. Similarly, the egress tunnel router might be the last-hop 388 router directly-connected to the destination host. Another example, 389 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 390 could be the site's border router at the service provider attachment 391 point. Mixing and matching of site-operated, ISP-operated, and other 392 tunnel routers is allowed for maximum flexibility. See Section 8 for 393 more details. 395 4.1. Packet Flow Sequence 397 This section provides an example of the unicast packet flow with the 398 following parameters: 400 o Source host "host1.abc.com" is sending a packet to 401 "host2.xyz.com". 403 o Each site is multi-homed, so each tunnel router has an address 404 (RLOC) assigned from each of the site's attached service provider 405 address blocks. 407 o The ITR and ETR are directly connected to the source and 408 destination, respectively. 410 Client host1.abc.com wants to communicate with server host2.xyz.com: 412 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 413 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 414 returned. This address is used as the destination EID and the 415 locally-assigned address of host1.abc.com is used as the source 416 EID. An IP/IPv6 packet is built using the EIDs in the IP/IPv6 417 header and sent to the default router. 419 2. The default router is configured as an ITR. It prepends a LISP 420 header to the packet, with one of its RLOCs as the source IP/IPv6 421 address and uses the destination EID from the original packet 422 header as the destination IP/IPv6 address. Subsequent packets 423 continue to behave the same way until a mapping is learned. 425 3. In LISP 1, the packet is routed through the Internet as it is 426 today. In LISP 1.5, the packet is routed on a different topology 427 which may have EID prefixes distributed and advertised in an 428 aggregatable fashion. In either case, the packet arrives at the 429 ETR. The router is configured to "punt" the packet to the 430 router's control-plane processor. See Section 7 for more 431 details. 433 4. The LISP header is stripped so that the packet can be forwarded 434 by the router control-plane. The router looks up the destination 435 EID in the router's EID-to-RLOC database (not the cache, but the 436 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 437 message is originated by the egress router and is addressed to 438 the source RLOC from the LISP header of the original packet (this 439 is the ITR). The source RLOC in the IP header of the UDP message 440 is one of the ETR's RLOCs (one of the RLOCs that is embedded in 441 the UDP payload). 443 5. The ITR receives the UDP message, parses the message (to check 444 for format validity) and stores the EID-to-RLOC information from 445 the packet. This information is put in the ITR's EID-to-RLOC 446 mapping cache (this is the on-demand cache, the cache where 447 entries time out due to inactivity). 449 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 450 a LISP header prepended with the RLOCs learned from the ETR. 452 7. The egress tunnel receives these packets directly (since the 453 destination address is one of its assigned IP addresses), strips 454 the LISP header and delivers the packets to the attached 455 destination host. 457 In order to eliminate the need for a mapping lookup in the reverse 458 direction, the ETR gleans RLOC information from the LISP header. 459 Both ITR and the ETR may also influence the decision the other makes 460 in selecting an RLOC. See Section 6 for more details. 462 5. Tunneling Details 464 This section describes the LISP Data Message which defines the 465 tunneling header used to encapsulate IPv4 and IPv6 packets which 466 contain EID addresses. Even though the following formats illustrate 467 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 468 combinations are supported as well. 470 Since additional tunnel headers are prepended, the packet becomes 471 larger and in theory can exceed the MTU of any link traversed from 472 the ITR to the ETR. It is recommended, in IPv4 that packets do not 473 get fragmented as they are encapsulated by the ITR. Instead, the 474 packet is dropped and an ICMP Too Big message is returned to the 475 source. 477 In practice, this is not really a problem. Hosts typically do not 478 originate IP packets larger than 1500 bytes. And second, a survey 479 has been taken (from a list of ISPs, see Acknowledgement section) 480 where nearly all ISP link MTUs are either 4470 bytes or support 481 Ethernet jumbo frames of 9000 bytes. Therefore, we don't anticipate 482 any problems with prepending additional headers. 484 5.1. LISP IPv4-in-IPv4 Header Format 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 OH | Time to Live | Protocol = 17 | Header Checksum | 494 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 \ | Source Routing Locator | 496 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 \ | Destination Routing Locator | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 / | Source Port = xxxx | Dest Port = 4342 | 500 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 \ | UDP length | UDP Checksum | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 / | Type | Locator Reach Bits | Nonce ... | 504 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 \ | ... Nonce | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 / |Version| IHL |Type of Service| Total Length | 508 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 / | Identification |Flags| Fragment Offset | 510 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 IH | Time to Live | Protocol | Header Checksum | 512 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 \ | Source EID | 514 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 \ | Destination EID | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 5.2. LISP IPv6-in-IPv6 Header Format 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 / |Version| Traffic Class | Flow Label | 522 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 / | Payload Length | Next Header=17| Hop Limit | 524 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 526 O + + 527 u | | 528 t + Source Routing Locator + 529 e | | 530 r + + 531 | | 532 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 d | | 534 r + + 535 | | 536 \ + Destination Routing Locator + 537 \ | | 538 \ + + 539 \ | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 / | Source Port = xxxx | Dest Port = 4342 | 542 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 \ | UDP length | UDP Checksum | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 / |Type=1 | Locator Reach Bits | Nonce ... | 546 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 \ | ... Nonce | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 / |Version| Traffic Class | Flow Label | 550 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 / | Payload Length | Next Header | Hop Limit | 552 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 I + + 555 n | | 556 n + Source EID + 557 e | | 558 r + + 559 | | 560 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 d | | 562 r + + 563 | | 565 \ + Destination EID + 566 \ | | 567 \ + + 568 \ | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 5.3. Tunnel Header Field Descriptions 573 IH Header: is the inner header, preserved from the datagram received 574 from the originating host. The source and destination IP 575 addresses are EIDs. 577 OH Header: is the outer header prepended by an ITR. The address 578 fields contain RLOCs obtained from the ingress router's EID-to- 579 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 581 UDP Header: contains a random source port allocated by the ITR when 582 encapsulating a packet. The destination port MUST be set to the 583 well-known IANA assigned port value 4342. The UDP checksum field 584 MUST be transmitted as 0 and not ignore by the ETR. 586 UDP Length: field contains the original packet's length. For an 587 IPv4 encapsulated packet, the inner header Total Length is copied. 588 For an IPv6 encapsualted packet, the inner header Payload Length 589 plus the size of the IPv6 header (40 bytes) is copied. 591 LISP Type: set to 1 to encode a LISP Data Message. 593 LISP Nonce: is an ITR randomly generated 6-byte value which tests 594 return routability of an ETR echoing back the none in a Map-Reply 595 message. 597 LISP Locator Reach Bits: in the LISP header are set by an ITR to 598 indicate to an ETR the reachability of the Locators in the source 599 site. Each RLOC in a Map-Reply is assigned an ordinal value from 600 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 601 Reach Bits are number from 0 to n-1 from the right significant bit 602 of the 12-bit field. When a bit is set to 1, the ITR is 603 indicating to the ETR the RLOC associated with the bit ordinal is 604 reachable. See Section 6.3 for details on how an ITR can 605 determine other site ITRs are reachable. 607 When doing Recursive Tunneling: 609 o The OH header Time to Live field (or Hop Limit field, in case of 610 IPv6) MUST be copied from the IH header Time to Live field. 612 o The OH header Type of Service field (or the Traffic Class field, 613 in the case of IPv6) SHOULD be copied from the IH header Type of 614 Service field. 616 When doing Re-encapsulated Tunneling: 618 o The new OH header Time to Live field SHOULD be copied from the 619 stripped OH header Time to Live field. 621 o The new OH header Type of Service field SHOULD be copied from the 622 stripped OH header Type of Service field. 624 Copying the TTL serves two purposes. First it preserves the distance 625 the host intended the packet to travel. And more importantly, it 626 provides for suppression of looping packets in the event there is a 627 loop of concatenated tunnels due to misconfiguration. 629 6. EID-to-RLOC Mapping 631 6.1. Control-Plane Packet Format 633 When LISP 1 or LISP 1.5 are used, new UDP packet types encode the 634 EID-to-RLOC mappings: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Version| IHL |Type of Service| Total Length | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Identification |Flags| Fragment Offset | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Time to Live | Protocol = 17 | Header Checksum | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Source Routing Locator | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Destination Routing Locator | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 / | Source Port | Dest Port | 650 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 \ | UDP length | UDP Checksum | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 | LISP Message | 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |Version| Traffic Class | Flow Label | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Payload Length | Next Header=17| Hop Limit | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 + + 665 | | 666 + Source Routing Locator + 667 | | 668 + + 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | | 672 + + 673 | | 674 + Destination Routing Locator + 675 | | 676 + + 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 / | Source Port | Dest Port | 680 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 \ | UDP length | UDP Checksum | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 | LISP Message | 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 The LISP UDP-based messages are the Map-Request and Map-Reply 689 messages. When a UDP Map-Request is sent, the UDP source port is 690 chosen by the sender and the destination UDP port number is set to 691 4342. When a UDP Map-Reply is sent, the source UDP port number is 692 set to 4342 and the destination UDP port number is copied from the 693 source port of either the Map-Request of the invoking data packet. 695 LISP-CONS [CONS] uses TCP with the same message formats. However, 696 this main LISP specification is the authoritative source for message 697 format definitions for the Map-Request and Map-Reply messages. 699 6.1.1. Map-Request Message Format 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Type | Locator Reach Bits | Checksum | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Nonce ... | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | ... Nonce | Record count |A| Reserved | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | ITR-AFI | CAR-AFI | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Originating ITR RLOC Address | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Originating CAR EID-Prefix | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Rec -> | EID mask-len | EID-AFI | EID-prefix ... | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Path Vector List | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Packet field descriptions: 721 Type: 2 (Map-Request) 723 Locator Reach Bits: Refer to Section 5.3. 725 Checksum: A complement of the 1-complements sum of the LISP packet. 726 The checksum MUST be computed and the UDP checksum MUST be set to 727 0. 729 Nonce: A 6-byte random value created by the sender of the Map- 730 Request. 732 Record count: The number of records in this request message. A 733 record comprises of what is labeled 'Rec" above and occurs the 734 number of times equal to Record count. 736 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 737 Requests sent by an ITR. See [CONS] for TCP-based Map-Requests. 739 Reserved: Set to 0 on transmission and ignored on receipt. 741 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 743 CAR-AFI: Address family of the "Originating CAR EID-Prefix" field. 745 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 746 [CONS] for TCP-based Map-Requests. 748 Originating CAR EID-Prefix: Set to 0 for UDP-based messages by an 749 ITR. See [CONS] for TCP-based Map-Requests. 751 EID mask-len: Mask length for EID prefix. 753 EID-AFI: Address family of EID-prefix according to [RFC2434] 755 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 756 address-family. 758 Path Vector List: See [CONS] for details. This field is not used in 759 UDP Map-Requests. 761 6.1.2. EID-to-RLOC UDP Map-Request Message 763 A Map-Request contains one or more EIDs encoded in prefix format with 764 a Locator count of 0. The EID-prefix MUST NOT be more specific than 765 a cache entry stored from a previously-received Map-Reply. 767 A Map-Request is sent from an ITR when it wants to test an RLOC for 768 reachability. This is performed by using the RLOC as the destination 769 address for Map-Request message with a randomly allocated source UDP 770 port number and the well-known destination port number 4342. A 771 successful Map-Reply updates the cached set of RLOCs associated with 772 the EID prefix range. 774 Map-Requests MUST be rate-limited. It is recommended that a Map- 775 Request for the same EID-prefix be sent no more than once per second. 777 6.1.3. Map-Reply Message Format 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Locator Reach Bits | Checksum | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Nonce ... | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | ... Nonce | Record count | Reserved | 785 +----> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | | Record TTL | 787 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | Locator count | EID mask-len |A| Reserved | 789 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 R | ITR-AFI | EID-AFI | 791 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 c | Originating ITR RLOC Address | 793 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 r | EID-prefix | 795 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | /| Priority | Weight | Unused | Loc-AFI | 797 | Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | \| Locator | 799 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Path Vector List | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Packet field descriptions: 805 Type: 3 (Map-Reply) 807 Locator Reach Bits: Refer to Section 5.3. 809 Checksum: A complement of the 1-complements sum of the LISP packet. 810 The checksum MUST be computed and the UDP checksum MUST be set to 811 0. 813 Nonce: A 6-byte value set in a data probe packet or a Map-Request 814 that is echoed here in the Map-Reply. 816 Record count: The number of records in this reply message. A record 817 comprises of what is labeled 'Record' above and occurs the number 818 of times equal to Record count. 820 Reserved: Set to 0 on transmission and ignored on receipt. 822 Record TTL: The time in minutes the recipient of the Map-Reply will 823 store the mapping. If the TTL is 0, the entry should be removed 824 from the cache immediately. If the value is 0xffffffff, the 825 recipient can decide locally how long to store the mapping. 827 Locator count: The number of Locator entries. A locator entry 828 comprises what is labeled above as 'Loc'. 830 EID mask-len: Mask length for EID prefix. 832 A: The Authoritative bit, when sent by a UDP-based message is always 833 set by the ETR. See [CONS] for TCP-based Map-Replies. 835 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 837 EID-AFI: Address family of EID-prefix according to [RFC2434]. 839 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 840 [CONS] for TCP-based Map-Replies. 842 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 843 address-family. 845 Priority: each RLOC is assigned a priority. Lower values are more 846 preferable. When multiple RLOCs have the same priority, they are 847 used in a load-split fashion. A value of 255 means the RLOC MUST 848 NOT be used. 850 Weight: when priorities are the same for multiple RLOCs, the weight 851 indicates how to balance traffic between them. Weight is encoded 852 as a percentage of total packets that match the mapping entry. If 853 a non-zero weight value is used for any RLOC, then all RLOCs must 854 use a non-zero weight value and then the sum of all weight values 855 MUST equal 100. What did the 3rd grader say after Steve Jobs gave 856 an iPhone demo to the class? If a zero value is used for any RLOC 857 weight, then all weights MUST be zero and the receiver of the Map- 858 Reply will decide how to load-split traffic. 860 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 861 assigned to an ETR or router acting as a proxy replier for the 862 EID-prefix. Note that the destination RLOC address MAY be an 863 anycast address if the tunnel egress point may be via more than 864 one physical device. A source RLOC can be an anycast address as 865 well. The source or destination RLOC MUST NOT be the broadcast 866 address (255.255.255.255 or any subnet broadcast address known to 867 the router), and MUST NOT be a link-local multicast address. The 868 source RLOC MUST NOT be a multicast address. The destination RLOC 869 SHOULD be a multicast address if it is being mapped from a 870 multicast destination EID. 872 Path Vector List: See [CONS] for details. This field is not used in 873 UDP Map-Replies. 875 6.1.4. EID-to-RLOC UDP Map-Reply Message 877 When a data packet triggers a Map-Reply to be sent, the RLOCs 878 associated with the EID-prefix matched by the EID in the original 879 packet destination IP address field will be returned. The RLOCs in 880 the Map-Reply are the globally-routable IP addresses of the ETR but 881 are not necessarily reachable; separate testing of reachability is 882 required. 884 Note that a Map-Reply may contain different EID-prefix granularity 885 (prefix + length) than the Map-Request which triggers it. This might 886 occur if a Map-Request were for a prefix that had been returned by an 887 earlier Map-Reply. In such a case, the requester updates its cache 888 with the new prefix information and granularity. For example, a 889 requester with two cached EID-prefixes that are covered by a Map- 890 Reply containing one, less-specific prefix, replaces the entry with 891 the less-specific EID-prefix. Note that the reverse, replacement of 892 one less-specific prefix with multiple more-specific prefixes, can 893 also occur but not by removing the less-specific prefix rather by 894 adding the more-specific prefixes which during a lookup will override 895 the less-specific prefix. 897 Replies SHOULD be sent for an EID-prefix no more often than once per 898 second to the same requesting router. For scalability, it is 899 expected that aggregation of EID addresses into EID-prefixes will 900 allow one Map-Reply to satisfy a mapping for the EID addresses in the 901 prefix range thereby reducing the number of Map-Request messages. 903 The addresses for a Data message or Map-Request message are swapped 904 and used for sending the Map-Reply. The UDP source and destination 905 ports are swapped as well. That is, the source port in the UDP 906 header for the Map-Reply is set to the well-known UDP port number 907 4342. 909 6.2. Routing Locator Selection 911 Both client-side and server-side may need control over the selection 912 of RLOCs for conversations between them. This control is achieved by 913 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 914 messages. Alternatively, RLOC information may be gleaned from 915 received tunneled packets or EID-to-RLOC Map-Request messages. 917 The following enumerates different scenarios for choosing RLOCs and 918 the controls that are available: 920 o Server-side returns one RLOC. Client-side can only use one RLOC. 921 Server-side has complete control of the selection. 923 o Server-side returns a list of RLOC where a subset of the list has 924 the same best priority. Client can only use the subset list 925 according to the weighting assigned by the server-side. In this 926 case, the server-side controls both the subset list and load- 927 splitting across its members. The client-side can use RLOCs 928 outside of the subset list if it determines that the subset list 929 is unreachable (unless RLOCs are set to a Priority of 255). Some 930 sharing of control exists: the server-side determines the 931 destination RLOC list and load distribution while the client-side 932 has the option of using alternatives to this list if RLOCs in the 933 list are unreachable. 935 o Server-side sets weight of 0 for the RLOC subset list. In this 936 case, the client-side can choose how the traffic load is spread 937 across the subset list. Control is shared by the server-side 938 determining the list and the client determining load distribution. 939 Again, the client can use alternative RLOCs if the server-provided 940 list of RLOCs are unreachable. 942 o Either side (more likely on the server-side ETR) decides not to 943 send an Map-Request. For example, if the server-side ETR does not 944 send Map-Requests, it gleans RLOCs from the client-side ITR, 945 giving the client-side ITR responsibility for bidirectional RLOC 946 reachability and preferability. Server-side ETR gleaning of the 947 client-side ITR RLOC is done by caching the inner header source 948 EID and the outer header source RLOC of received packets. The 949 client-side ITR controls how traffic is returned and can alternate 950 using an outer header source RLOC, which then can be added to the 951 list the server-side ETR uses to return traffic. Since no 952 Priority or Weights are provided using this method, the server- 953 side ETR must assume each client-side ITR RLOC uses the same best 954 Priority with a Weight of zero. In addition, since EID-prefix 955 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 956 on tunnel routers can grow to be very large. 958 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 959 reachable. The Map-Reply and the database mapping service does not 960 provide any reachability status for Locators. This is done outside 961 of the mapping service. See next section for details. 963 6.3. Routing Locator Reachability 965 There are 4 methods for determining when a Locator is either 966 reachable or has become unreachable: 968 1. Locator reachability is determined by an ETR by examining the 969 Loc-Reach-Bits from a LISP header of a Data Message which is 970 provided by an ITR when an ITR encapsulates data. 972 2. Locator unreachability is determined by an ITR by receiving ICMP 973 Network or Host Unreachable messages. 975 3. ETR unreachability is determined when a host sends an ICMP Port 976 Unreachable message. 978 4. Locator reachability is determined by receiving a Map-Reply 979 message from a ETR's Locator address in response to a previously 980 sent Map-Request. 982 When determining Locator reachability by examining the Loc-Reach-Bits 983 from the LISP Data Message, an ETR will receive up to date status 984 from the ITR closest to the Locators at the source site. The ITRs at 985 the source site can determine reachability when running their IGP at 986 the site. When the ITRs are deployed on CE routers, typically a 987 default route is injected into the site's IGP from each of the ITRs. 988 If an ITR goes down, the CE-PE link goes down, or the PE router goes 989 down, the CE router withdraws the default route. This allows the 990 other ITRs at the site to determine one of the Locators has gone 991 unreachable. 993 The Locators listed in a Map-Reply are numbered with ordinals 0 to 994 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 995 to n-1 starting with the least signfiicant bit numbered as 0. So, 996 for example, if the ITR with locator listed as the 3rd Locator 997 position in the Map-Reply goes down, all other ITRs at the site will 998 have the 3rd bit from the right cleared (the bit that corresponds to 999 ordinal 2). 1001 When an ETR decapsulates a packet, it will look for a change in the 1002 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1003 refrain from encapsulating packets to the Locator that has just gone 1004 unreachable. It can start using the Locator again when the bit that 1005 corresponds to the Locator goes from 0 to 1. 1007 When ITRs at the site are not deployed in CE routers, the IGP can 1008 still be used to determine the reachability of Locators provided they 1009 are injected a stub links into the IGP. This is typically done when 1010 a /32 address is configured on a loopback interface. 1012 When ITRs receive ICMP Network or Host Unreachable messages as a 1013 method to determine unreachability, they will refrain from using 1014 Locators which are described in Locator lists of Map-Replies. 1015 However, using this approach is unreliable because many network 1016 operators turn off generation of ICMP Unreachable messages. 1018 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1019 Reply is returned, reachability of the Locator has been achieved. 1020 Obviously, sending such probes increases the number of control 1021 messages originated by tunnel routers for active flows, so Locators 1022 are assumed to be reachable when they are advertised. 1024 This assumption does create a dependency: Locator unreachability is 1025 detected by the receipt of ICMP Host Unreachable messages. When an 1026 Locator has been determined unreachable, it is not used for active 1027 traffic; this is the same as if it were listed in a Map-Reply with 1028 priority 255. 1030 The ITR can later test the reachability of the unreachable Locator by 1031 sending periodic Requests. Both Requests and Replies MUST be rate- 1032 limited. Locator reachability testing is never done with data 1033 packets since that increases the risk of packet loss for end-to-end 1034 sessions. 1036 7. Router Performance Considerations 1038 LISP is designed to be very hardware-based forwarding friendly. By 1039 doing tunnel header prepending [RFC1955] and stripping instead of re- 1040 writing addresses, existing hardware could support the forwarding 1041 model with little or no modification. Where modifications are 1042 required, they should be limited to re-programming existing hardware 1043 rather than requiring expensive design changes to hard-coded 1044 algorithms in silicon. 1046 A few implementation techniques can be used to incrementally 1047 implement LISP: 1049 o When a tunnel encapsulated packet is received by an ETR, the outer 1050 destination address may not be the address of the router. This 1051 makes it challenging for the control-plane to get packets from the 1052 hardware. This may be mitigated by creating special FIB entries 1053 for the EID-prefixes of EIDs served by the ETR (those for which 1054 the router provides an RLOC translation). These FIB entries are 1055 marked with a flag indicating that control-plane processing should 1056 be performed. The forwarding logic of testing for particular IP 1057 protocol number value is not necessary. No changes to existing, 1058 deployed hardware should be needed to support this. 1060 o On an ITR, prepending a new IP header is as simple as adding more 1061 bytes to a MAC rewrite string and prepending the string as part of 1062 the outgoing encapsulation procedure. Many routers that support 1063 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1064 support this action. 1066 o When a received packet's outer destination address contains an EID 1067 which is not intended to be forwarded on the routable topology 1068 (i.e. LISP 1.5), the source address of a data packet or the 1069 router interface with which the source is associated (the 1070 interface from which it was received) can be associated with a VRF 1071 (Virtual Routing/Forwarding), in which a different (i.e. non- 1072 congruent) topology can be used to find EID-to-RLOC mappings. 1074 8. Deployment Scenarios 1076 This section will explore how and where ITRs and ETRs can be deployed 1077 and will discuss the pros and cons of each deployment scenario. 1078 There are two basic deployment tradeoffs to consider: centralized 1079 versus distributed caches and flat, recursive, or re-encapsulating 1080 tunneling. 1082 When deciding on centralized versus distributed caching, the 1083 following issues should be considered: 1085 o Are the tunnel routers spread out so that the caches are spread 1086 across all the memories of each router? 1088 o Should management "touch points" be minimized by choosing few 1089 tunnel routers, just enough for redundancy? 1091 o In general, using more ITRs doesn't increase management load, 1092 since caches are built and stored dynamically. On the other hand, 1093 more ETRs does require more management since EID-prefix-to-RLOC 1094 mappings need to be explicitly configured. 1096 When deciding on flat, recursive, or re-encapsulation tunneling, the 1097 following issues should be considered: 1099 o Flat tunneling implements a single tunnel between source site and 1100 destination site. This generally offers better paths between 1101 sources and destinations with a single tunnel path. 1103 o Recursive tunneling is when tunneled traffic is again further 1104 encapsulated in another tunnel, either to implement VPNs or to 1105 perform Traffic Engineering. When doing VPN-based tunneling, the 1106 site has some control since the site is prepending a new tunnel 1107 header. In the case of TE-based tunneling, the site may have 1108 control if it is prepending a new tunnel header, but if the site's 1109 ISP is doing the TE, then the site has no control. Recursive 1110 tunneling generally will result in suboptimal paths but at the 1111 benefit of steering traffic to resource available parts of the 1112 network. 1114 o The technique of re-encapsulation ensures that packets only 1115 require one tunnel header. So if a packet needs to be rerouted, 1116 it is first decapsulated by the ETR and then re-encapsulated with 1117 a new tunnel header using a new RLOC. 1119 The next sub-sections will describe where tunnel routers can reside 1120 in the network. 1122 8.1. First-hop/Last-hop Tunnel Routers 1124 By locating tunnel routers close to hosts, the EID-prefix set is at 1125 the granularity of an IP subnet. So at the expense of more EID- 1126 prefix-to-RLOC sets for the site, the caches in each tunnel router 1127 can remain relatively small. But caches always depend on the number 1128 of non-aggregated EID destination flows active through these tunnel 1129 routers. 1131 With more tunnel routers doing encapsulation, the increase in control 1132 traffic grows as well: since the EID-granularity is greater, more 1133 Map-Requests and replies are traveling between more routers. 1135 The advantage of placing the caches and databases at these stub 1136 routers is that the products deployed in this part of the network 1137 have better price-memory ratios then their core router counterparts. 1138 Memory is typically less expensive in these devices and fewer routes 1139 are stored (only IGP routes). These devices tend to have excess 1140 capacity, both for forwarding and routing state. 1142 LISP functionality can also be deployed in edge switches. These 1143 devices generally have layer-2 ports facing hosts and layer-3 ports 1144 facing the Internet. Spare capacity is also often available in these 1145 devices as well. 1147 8.2. Border/Edge Tunnel Routers 1149 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1150 space associated with a site to be reachable via a small set of RLOCs 1151 assigned to the CE routers for that site. 1153 This offers the opposite benefit of the first-hop/last-hop tunnel 1154 router scenario: the number of mapping entries and network management 1155 touch points are reduced, allowing better scaling. 1157 One disadvantage is that less of the network's resources are used to 1158 reach host endpoints thereby centralizing the point-of-failure domain 1159 and creating network choke points at the CE router. 1161 Note that more than one CE router at a site can be configured with 1162 the same IP address. In this case an RLOC is an anycast address. 1163 This allows resilency between the CE routers. That is, if a CE 1164 router fails, traffic is automatically routed to the other routers 1165 using the same anycast address. However, this comes with the 1166 disadvantage where the site cannot control the entrance point when 1167 the anycast route is advertised out from all border routers. 1169 8.3. ISP Provider-Edge (PE) Tunnel Routers 1171 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1172 over the location of the egress tunnel endpoints. That is, the ISP 1173 can decide if the tunnel endpoints are in the destination site (in 1174 either CE routers or last-hop routers within a site) or at other PE 1175 edges. The advantage of this case is that two or more tunnel headers 1176 can be avoided. By having the PE be the first router on the path to 1177 encapsulate, it can choose a TE path first, and the ETR can 1178 decapsulate and re-encapsulate for a tunnel to the destination end 1179 site. 1181 An obvious disadvantage is that the end site has no control over 1182 where its packets flow or the RLOCs used. 1184 As mentioned in earlier sections a combination of these scenarios is 1185 possible at the expense of extra packet header overhead, if both site 1186 and provider want control, then recursive or re-encapsulating tunnels 1187 are used. 1189 9. Multicast Considerations 1191 A multicast group address, as defined in the original Internet 1192 architecture is an identifier of a grouping of topologically 1193 independent receiver host locations. The address encoding itself 1194 does not determine the location of the receiver(s). The multicast 1195 routing protocol, and the network-based state the protocol creates, 1196 determines where the receivers are located. 1198 In the context of LISP, a multicast group address is both an EID and 1199 a Routing Locator. Therefore, no specific semantic or action needs 1200 to be taken for a destination address, as it would appear in an IP 1201 header. Therefore, a group address that appears in an inner IP 1202 header built by a source host will be used as the destination EID. 1203 And the outer IP header (the destination Routing Locator address), 1204 prepended by a LISP router, will use the same group address as the 1205 destination Routing Locator. 1207 Having said that, only the source EID and source Routing Locator 1208 needs to be dealt with. Therefore, an ITR merely needs to put its 1209 own IP address in the source Routing Locator field when prepending 1210 the outer IP header. This source Routing Locator address, like any 1211 other Routing Locator address MUST be globally routable. 1213 Therefore, an EID-to-RLOC mapping does not need to be performed by an 1214 ITR when a received data packet is a multicast data packet or when 1215 processing a source-specific Join (either by IGMPv3 or PIM). But the 1216 source Routing Locator is decided by the multicast routing protocol 1217 in a receiver site. That is, an EID to Routing Locator translation 1218 is done at control-time. 1220 Another approach is to have the ITR not encapsulate a multicast 1221 packet and allow the the host built packet to flow into the core even 1222 if the source address is allocated out of the EID namespace. If the 1223 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 1224 can RPF to the ITR (the Locator address which is injected into core 1225 routing) rather than the host source address (the EID address which 1226 is not injected into core routing). 1228 10. Security Considerations 1230 We believe that most of the security mechanisms will be part of the 1231 mapping database service when using control-plane procedures for 1232 obtaining EID-to-RLOC mappings. For data-plane triggered mappings, 1233 as described in this specification, protection is provided against 1234 ETR spoofing by using Return- Routeability mechanisms evidenced by 1235 the use of a 6-byte Nonce field in the LISP encapsulation header. 1236 The nonce, coupled with the ITR accepting only solicited Map-Replies 1237 goes a long way towards providing decent authentication. 1239 LISP does not rely on a PKI infrastructure or a more heavy weight 1240 authentication system. These systems challenge the scalability of 1241 LISP which was a primary design goal. 1243 DoS attack prevention will depend on implementations rate- limiting 1244 of Map-Requests and Map-Replies to the control-plane as well as rate- 1245 limiting the number of data triggered Map-Replies. 1247 11. Prototype Plans and Status 1249 The operator community has requested that the IETF take a practical 1250 approach to solving the scaling problems associated with global 1251 routing state growth. This document offers a simple solution which 1252 is intended for use in a pilot program to gain experience in working 1253 on this problem. 1255 The authors hope that publishing this specification will allow the 1256 rapid implementation of multiple vendor prototypes and deployment on 1257 a small scale. Doing this will help the community: 1259 o Decide whether a new EID-to-RLOC mapping database infrastructure 1260 is needed or if a simple, UDP-based, data-triggered approach is 1261 flexible and robust enough. 1263 o Experiment with provider-independent assignment of EIDs while at 1264 the same time decreasing the size of DFZ routing tables through 1265 the use of topologically-aligned, provider-based RLOCs. 1267 o Determine whether multiple levels of tunneling can be used by ISPs 1268 to achieve their Traffic Engineering goals while simultaneously 1269 removing the more specific routes currently injected into the 1270 global routing system for this purpose. 1272 o Experiment with mobility to determine if both acceptable 1273 convergence and session survivability properties can be scalably 1274 implemented to support both individual device roaming and site 1275 service provider changes. 1277 Here are a rough set of milestones: 1279 1. Stabilize this draft by Summer 2007 Chicago IETF. 1281 2. Start implementations to report on by Summer 2007 Chicago IETF. 1283 3. Start pilot deployment between summer and fall IETFs. Report on 1284 deployment at Fall 2007 Vancouver IETF. 1286 4. Achieve multi-vendor interoperability by Fall 2007 Vancouver 1287 IETF. 1289 5. Consider prototyping other database lookup schemes, be it DNS, 1290 DHTs, CONS, NERD, or other mechanisms by Fall 2007 IETF. 1292 As of this writing the following accomplishments have been achieved: 1294 1. A unit tested software switching implementation has been 1295 completed for both IPv4 and IPv6 encapsulations for LISP 1 and 1296 LISP 1.5 functionality. 1298 2. Dave Meyer, Vince Fuller, and Darrel Lewis are testing the 1299 implementation this summer. 1301 3. An implementation of LISP-CONS is under way. 1303 Please contact authors if interested in doing an implementation and 1304 want to interoperability test with our implementation. 1306 12. References 1308 12.1. Normative References 1310 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1311 August 1980. 1313 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1314 Destinations", RFC 1498, August 1993. 1316 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1317 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1320 Requirement Levels", BCP 14, RFC 2119, March 1997. 1322 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1323 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1324 October 1998. 1326 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1327 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1328 March 2000. 1330 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1331 via IPv4 Clouds", RFC 3056, February 2001. 1333 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1334 (HIP) Architecture", RFC 4423, May 2006. 1336 12.2. Informative References 1338 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1339 NUMBERS http://www.iana.org/numbers.html, February 2007. 1341 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1342 L. Zhang, "APT: A Practical Transit Mapping Service", 1343 draft-jen-apt-00.txt (work in progress), July 2007. 1345 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 1346 Enhancement to the Internet Architecture", Internet- 1347 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1348 1999. 1350 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 1351 Content distribution Overlay Network Service for LISP", 1352 draft-meyer-lisp-cons-01.txt (work in progress), 1353 July 2007. 1355 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 1356 Algorithms for DHTs: Some Open Questions", PDF 1357 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 1359 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 1360 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 1362 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1363 "Locator/ID Separation Protocol (LISP1) [Routable ID 1364 Version]", 1365 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 1366 October 2006. 1368 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1369 "Locator/ID Separation Protocol (LISP2) [DNS-based 1370 Version]", 1371 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 1372 November 2006. 1374 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1375 draft-lear-lisp-nerd-01.txt (work in progress), June 2007. 1377 [RAWS] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1378 Workshop on Routing and Addressing", 1379 draft-iab-raws-report-02.txt (work in progress), 1380 April 2007. 1382 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1383 TLV", draft-ietf-pim-rpf-vector-03.txt (work in progress), 1384 October 2006. 1386 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 1387 for Routing Protocol Meta-data Dissemination", 1388 draft-handley-p2ppush-unpublished-2007726.txt (work in 1389 progress), July 2007. 1391 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1392 protocol", draft-ietf-shim6-proto-06.txt (work in 1393 progress), October 2006. 1395 Appendix A. Acknowledgments 1397 The authors would like to gratefully acknowledge many people who have 1398 contributed discussion and ideas to the making of this proposal. 1399 They include Jason Schiller, Lixia Zhang, Dorian Kim, Peter 1400 Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David Conrad, 1401 Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, 1402 Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Scott Brim, 1403 Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi 1404 Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger 1405 Jorgensen, and John Zwiebel. 1407 In particular, we would like to thank Dave Meyer for his clever 1408 suggestion for the name "LISP". ;-) 1410 Authors' Addresses 1412 Dino Farinacci 1413 cisco Systems 1414 Tasman Drive 1415 San Jose, CA 95134 1416 USA 1418 Email: dino@cisco.com 1420 Vince Fuller 1421 cisco Systems 1422 Tasman Drive 1423 San Jose, CA 95134 1424 USA 1426 Email: vaf@cisco.com 1428 Dave Oran 1429 cisco Systems 1430 7 Ladyslipper Lane 1431 Acton, MA 1432 USA 1434 Email: oran@cisco.com 1436 Dave Meyer 1437 cisco Systems 1438 170 Tasman Drive 1439 San Jose, CA 1440 USA 1442 Email: dmm@cisco.com 1444 Full Copyright Statement 1446 Copyright (C) The IETF Trust (2007). 1448 This document is subject to the rights, licenses and restrictions 1449 contained in BCP 78, and except as set forth therein, the authors 1450 retain all their rights. 1452 This document and the information contained herein are provided on an 1453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1455 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1456 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1457 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1460 Intellectual Property 1462 The IETF takes no position regarding the validity or scope of any 1463 Intellectual Property Rights or other rights that might be claimed to 1464 pertain to the implementation or use of the technology described in 1465 this document or the extent to which any license under such rights 1466 might or might not be available; nor does it represent that it has 1467 made any independent effort to identify any such rights. Information 1468 on the procedures with respect to rights in RFC documents can be 1469 found in BCP 78 and BCP 79. 1471 Copies of IPR disclosures made to the IETF Secretariat and any 1472 assurances of licenses to be made available, or the result of an 1473 attempt made to obtain a general license or permission for the use of 1474 such proprietary rights by implementers or users of this 1475 specification can be obtained from the IETF on-line IPR repository at 1476 http://www.ietf.org/ipr. 1478 The IETF invites any interested party to bring to its attention any 1479 copyrights, patents or patent applications, or other proprietary 1480 rights that may cover technology that may be required to implement 1481 this standard. Please address the information to the IETF at 1482 ietf-ipr@ietf.org. 1484 Acknowledgment 1486 Funding for the RFC Editor function is provided by the IETF 1487 Administrative Support Activity (IASA).