idnits 2.17.1 draft-curran-lisp-emacs-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Without any join filters, it is possible for anyone to join any group. A node could join all groups in order to find out which sites are talking to which other sites. This is sometimes not acceptable. Therefore group join filters are required. At the points where a particular ETR will join, "join" messages to the groups for EID prefixes which that ETR handles MUST be allowed, but more SHOULD not be. This configuration is limited, simple, related to configuration that will already be done, and scalable. -- 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 (November 9, 2007) is 6014 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-04 == Outdated reference: A later version (-01) exists of draft-jen-apt-00 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-02 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Brim 3 Internet-Draft D. Farinacci 4 Intended status: Experimental D. Meyer 5 Expires: May 12, 2008 Cisco Systems, Inc. 6 J. Curran 7 ServerVault 8 November 9, 2007 10 EID Mappings Multicast Across Cooperating Systems for LISP 11 draft-curran-lisp-emacs-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 12, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 One of the potential problems with the "map-and-encapsulate" 45 approaches to routing architecture is that there is a significant 46 chance of packets being dropped while a mapping is being retrieved. 47 Some approaches pre-load ingress tunnel routers with at least part of 48 the mapping database. Some approaches try to solve this by providing 49 intermediate "default" routers which have a great deal more knowledge 50 than a typical ingress tunnel router. This document proposes a 51 scheme which does not drop packets yet does not require a great deal 52 of knowledge in any router. However, there are still some issues 53 that need to be worked out. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Detailed Discussion . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Assignment of rendezvous point addresses to groups . . . . 5 68 4.2. Determination of the Right Group to Join . . . . . . . . . 6 69 4.3. Sending a Packet . . . . . . . . . . . . . . . . . . . . . 6 70 4.4. Path Stretch . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.5. Requirement for Multicast Deployment . . . . . . . . . . . 7 72 4.6. Protection against Snoopers . . . . . . . . . . . . . . . 7 73 4.7. ETR Initial Packet Forwarding . . . . . . . . . . . . . . 7 74 4.8. Responding with a Map-Reply . . . . . . . . . . . . . . . 8 75 4.9. Authentication of the Map-Reply . . . . . . . . . . . . . 8 76 4.10. Transition Scenarios . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 Intellectual Property and Copyright Statements . . . . . . . . . . 11 86 1. Introduction 88 One of the potential problems with the "map-and-encapsulate" 89 approaches to routing architecture is that there is a significant 90 chance of packets being dropped while a mapping is being retrieved. 91 Some approaches pre-load ingress tunnel routers (ITRs) with at least 92 part of the mapping database. Some approaches try to solve this by 93 providing intermediate "default" routers which have a great deal more 94 knowledge than a typical ingress tunnel router. This document 95 proposes a scheme which does not drop packets yet does not require a 96 great deal of knowledge in any router. However, there are still some 97 issues that need to be worked out. 99 2. Problem Statement 101 LISP [I-D.farinacci-lisp] assumes a mechanism for obtaining mappings 102 from EID to RLOC exists, but does not require or assume any specific 103 mapping mechanism. Among those proposed for use with LISP are LISP- 104 ALT [I-D.fuller-lisp-alt],NERD [I-D.lear-lisp-nerd], CONS 105 [I-D.meyer-lisp-cons], and APT [I-D.jen-apt]. Others have also been 106 considered. 108 These mechanisms attempt in various ways to balance database size and 109 churn with the delay of looking up a mapping for the first packet 110 between two sites. If complete mapping information is pushed all the 111 way to the ITRs, then there is no delay in looking up the first 112 mapping, but each ITR must hold a large amount of information and be 113 able to keep it up to date. If mapping information is not pushed at 114 all (as in CONS), then an ITR need only hold the information it 115 decides to cache, but there may be significant delays in retrieving a 116 mapping for the first packets sent between two sites, and those 117 packets may be dropped. Hybrid schemes, where mapping information is 118 pushed partway to the ITRs, have been proposed, but the tradeoff 119 between database size/churn and lookup delay is still not solved 120 satisfactorily. 122 "Default forwarders" have been proposed in CONS, APT, and CRIO 123 [CRIO]. These are intermediate forwarding points. The intent is 124 that if an ITR does not have a mapping for a packet, it will forward 125 the packet to the default forwarder. The assumption is that the 126 default forwarder serves an aggregate of endpoints, and will thus 127 have better knowledge of how to reach the destination. This 128 eliminates mapping lookup delay and the possibility of dropped 129 packets, at the cost of possibly having the first packets sent 130 between two sites take a longer path. There are two kinds of default 131 forwarders, those that represent multiple sources and those that 132 represent multiple destinations. 134 o Source-side default forwarders (SSDFs) serve a group of sources, 135 for example a site or all customers of an IP service provider. 136 The belief is that a source-side default forwarder can have more 137 mapping entries than the usual ITR, either because more can be 138 pushed to it or because it will have more entries cached, since it 139 is serving more queries. If it does not have a mapping for the 140 destination it will use one of the mapping mechanisms on behalf of 141 the source. Source-side default forwarders do not actually change 142 the problem, they simply move the problem from the ITR to an 143 intermediary. The same tradeoff, of having high rate/state versus 144 dropping packets versus delay, is still there. The advantage is 145 that they concentrate the problem so that costs can be 146 concentrated as well, but in most cases an SSDF would have 147 performance requirements at the level of a high end router. Valid 148 packets can still be dropped if the SSDF does not itself have a 149 mapping. Another disadvantage is that since they offer a general 150 "default" route, bogus packets will get forwarded to and possibly 151 through them instead of being dropped (for no route). 153 o Destination-side default forwarders (DSDFs) serve a group of 154 destinations. For example, if a source sends a packet to 155 192.168.100.1 and its ITR does not have a mapping entry for that 156 packet, the ITR might forward the packet to a default forwarder 157 responsible for all of 192.168.0.0/16. A destination-side 158 forwarder has a mapping database which is complete, but only for a 159 subset of the Internet, so it does not have the high performance 160 requirements of a mainstream source-side default forwarder. Most 161 bogus packets are not forwarded because ITRs will only have routes 162 to DSDFs for valid EID prefixes. A potential downside to DSDFs is 163 that since they represent an aggregate of destinations, the path 164 to the destination through the DSDF may see some stretch. 166 Destination-side default forwarders look like a good idea if some 167 issues can be dealt with. They can eliminate the possibility of 168 dropped packets. Delay for first packets exchanged between sites has 169 a possibility of being long for some sites, depending on how DSDFs 170 are organized. They still hold part of the mapping database, and 171 need to maintain its accuracy. Also a mechanism is needed for 172 sources, and the routers near sources, to determine which SSDF 173 handles which prefixes. Finally, the mechanism by which the 174 forwarding path is moved toward optimality needs to be secure. 176 This draft proposes a mechanism using destination-side default 177 forwarders that has low "rate*state" overhead, has easy DSDF 178 location, and controls path stretch. It is called "EID-mappings 179 Multicast Across Cooperating Systems for LISP", or EMACS-LISP. 181 3. Overview 183 The mechanism by which DSDFs forward packets to the appropriate ETRs 184 is bidirectional PIM [RFC5015] multicast trees. Briefly: 186 o In order to keep the number of multicast trees reasonable, each 187 tree handles a subset of the entire EID address space. In IPv4 188 this might be a /16. 190 o An ETR responsible for an EID prefix, for example 191 192.168.100.0/24, joins an appropriate multicast group for an 192 including prefix, for example 192.168.0.0/16. An ETR responsible 193 for an EID prefix larger than an including prefix, or for multiple 194 EID prefixes in different including prefixes, will need to join 195 multiple groups. Multiple ETRs for a site might join the group. 197 o The bidirectional PIM tree rendezvous point addresses, and the 198 groups they are rendezvous points for, are advertised in 199 multiprocotol eBGP. This instance of eBGP runs in an overlay GRE 200 infrastructure, distinct from the eBGP instance which will be used 201 for normal RLOC routing in the Internet core. 203 o When an ITR needs to forward a packet and does not have a LISP 204 EID->RLOC mapping, it uses an algorithm to find the correct 205 multicast group, and sends the packet to that group, on the 206 overlay GRE infrastructure. The outer destination RLOC is the 207 multicast address. The outer source RLOC is the ITR's. 209 o The packets travel to all registered recipients. Most of them 210 examine the packet and realize they are not responsible for the 211 destination, so they throw it away. Among the ETRs which are 212 responsible for the EID prefix, one or more will send a LISP Map- 213 Reply back to the originating ITR, providing a specific mapping, 214 so that the ITR can send all further packets directly. 216 Thus the first one or two packets sent between two sites will 217 experience more delay than following packets, but no packets are 218 dropped unless they should be. 220 Details are added, and issues discussed, in the following sections. 222 4. Detailed Discussion 224 4.1. Assignment of rendezvous point addresses to groups 226 Rendezous point addresses (RPAs) are not necessarily related to 227 anything physical. Their determination does not need to be covered 228 in this document, as long as they can be advertised in the overlay 229 eBGP instance. 231 4.2. Determination of the Right Group to Join 233 An ETR must join one or more multicast groups in order to receive 234 packets to the EID prefixes it is responsible for. There must be 235 agreement among the ETRs for a prefix and the ITRs that want to send 236 to that prefix on how the correct multicast group is determined. To 237 avoid mapping retrieval delay, the multicast group must be 238 determinable without querying a server. The following mechanism for 239 mapping from destination EID to multicast group address MUST be 240 supported for 32-bit EIDs: 242 o There is a /16 in IPv4 multicast address space allocated for use 243 by this protocol, for example 238.1.0.0/16. There are 64k groups, 244 one for each of 64k "including" prefixes. 246 o The RP addresses of all valid groups are advertised in eBGP, along 247 with group addresses. The next_hop for a group address is the 248 RP's address. 250 o An ETR responsible for an EID prefix will mask out the higher 251 order 16 bits of that EID prefix, and OR those bits into the lower 252 order 16 bits of 238.1.0.0 to get the group to join. For example, 253 for the EID prefix 192.168.100.0/24, the ETR will join multicast 254 group 238.1.192.168. 256 o If an ETR handles traffic to an EID prefix shorter than a /16, it 257 will join all groups necessary to cover it. 259 o The ETR joins those groups, on the GRE overlay. 261 A similar mechanism can be defined for IPv6. Only valid groups, 262 known to contain EID prefixes participating in LISP, will be 263 advertised in the eBGP instance. Therefore it is all right to define 264 the IPv6 mechanism in a way that allows for a large number of groups. 266 4.3. Sending a Packet 268 ITRs participate in the eBGP instance running on the GRE overlay, so 269 that they receive information on available groups and rendezvous 270 point addresses. Packets for which the ITR does not have a direct 271 lisp EID->RLOC mapping cached, does not have a route to an 272 appropriate multicast group, and does not have a direct route for, 273 and are dropped. To send a packet on the multicast overlay, the ITR 274 encapsulates the packet with a LISP header. The destination address 275 is the group determined by the same algorithm as above (Section 4.2). 277 The source address is an RLOC for the ITR, or at least an RLOC for 278 the source site. 280 4.4. Path Stretch 282 The first packets sent between two sites will be multicast. 283 Depending on how the multicast tree is assembled this may not be a 284 direct path. How sub-optimal these paths would be is for further 285 study. 287 4.5. Requirement for Multicast Deployment 289 A potential concern with this approach is that it will require 290 multicast support in all of the routers in the Internet core. 291 However, the only nodes interested in the multicast routes are xTRs. 292 They will participate in an overlay tunneled infrastructure, for 293 example over GRE. eBGP, bidirectional PIM, and the multicast packets 294 themselves would all travel over this tunneled infrastructure. The 295 only nodes that need know or care about multicast are the ones that 296 want to use it. The overhead of constructing and maintaining the GRE 297 overlay is for further study. 299 4.6. Protection against Snoopers 301 Without any join filters, it is possible for anyone to join any 302 group. A node could join all groups in order to find out which sites 303 are talking to which other sites. This is sometimes not acceptable. 304 Therefore group join filters are required. At the points where a 305 particular ETR will join, "join" messages to the groups for EID 306 prefixes which that ETR handles MUST be allowed, but more SHOULD not 307 be. This configuration is limited, simple, related to configuration 308 that will already be done, and scalable. 310 4.7. ETR Initial Packet Forwarding 312 When a packet is multicast it is distributed to all potentially 313 interested ETRs. ETRs that are not responsible for an EID prefix 314 containing the packet's destination address will discard the packet. 315 ETRs which do handle traffic for the destination EID SHOULD decide 316 among themselves who will forward the packet, since duplicate packets 317 can sometimes be a problem. They do so by position in the LISP RLOC- 318 set (see LISP [I-D.farinacci-lisp]). The ETR which is active and has 319 the lowest ordinal position in the RLOC-set will forward the packet. 321 Note: there can be a serious problem if a small site has an EID 322 prefix in the same /16 including prefix as a large site. In that 323 case, the small site's ETRs would get all of the initial traffic to 324 the large site and have to throw it all away. This could overwhelm a 325 small site's ETR. This problem, and possibly how to focus some 326 multicast groups, is for further study. 328 4.8. Responding with a Map-Reply 330 At least one receiving ETR SHOULD unicast a Map-Reply directly back 331 to the originating ITR, so that future packets will be sent directly 332 to the ETR, not via the multicast infrastructure. As with packet 333 delivery (Section 4.7), the active ETR with the lowest ordinal 334 position in the LISP RLOC-set will be the one to respond. 336 4.9. Authentication of the Map-Reply 338 Because an initial packet can go to multiple sites, an ITR SHOULD 339 authenticate any received Map-Reply messages. Otherwise it may 340 misroute future packets. Nonces are not an adequate measure. Some 341 kind of signature is required on the content of the Map-Reply. The 342 trade-offs here are for further study. 344 4.10. Transition Scenarios 346 To be filled in. Possibilities include using LISP-ALT as an 347 intermediate approach, using alternative DNS resources, and sending 348 initial packets via multiple paths. 350 5. IANA Considerations 352 This section will be filled in later. 354 A new SAFI will be needed to carry both rendezvous point addresses 355 and group addresses. 357 A set of at least 64k multicast groups is needed, and it would be 358 better if a /8 were allocated, to be sure. Allocation of 238.0.0.0/8 359 is requested. 361 A similar request for IPv6 address space will be made after further 362 study. 364 Note to RFC Editor: this section may be removed on publication as an 365 RFC. 367 6. Security Considerations 369 To be filled in. Known issues are 370 o Revealing first packets to destinations which are not the source's 371 intended destination. 373 o Inviting map-reply responses off the path between source and 374 destination. 376 o Denial of service attacks on the multicast infrastructure. 378 o Potentially overloading ETRs with unwanted traffic. 380 7. Contributors 382 The authors are grateful for the help of those who offered comments, 383 notably Vince Fuller, Eliot Lear, Darrel Lewis, and David Oran. 385 8. References 387 8.1. Normative References 389 [I-D.farinacci-lisp] 390 Farinacci, D., "Locator/ID Separation Protocol (LISP)", 391 draft-farinacci-lisp-04 (work in progress), August 2007. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 397 "Bidirectional Protocol Independent Multicast (BIDIR- 398 PIM)", RFC 5015, October 2007. 400 8.2. Informative References 402 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "Scaling 403 IP Routing with the Core Router-Integrated Overlay", 404 November 2006. 406 [I-D.fuller-lisp-alt] 407 Fuller, V., "LISP-ALT", Internet-Draft not yet published. 409 [I-D.jen-apt] 410 Jen, D., "APT: A Practical Transit Mapping Service", 411 draft-jen-apt-00 (work in progress), July 2007. 413 [I-D.lear-lisp-nerd] 414 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 415 draft-lear-lisp-nerd-02 (work in progress), 416 September 2007. 418 [I-D.meyer-lisp-cons] 419 Brim, S., "LISP-CONS: A Content distribution Overlay 420 Network Service for LISP", draft-meyer-lisp-cons-02 (work 421 in progress), September 2007. 423 Authors' Addresses 425 Scott Brim 426 Cisco Systems, Inc. 428 Email: swb@employees.org 430 Dino Farinacci 431 Cisco Systems, Inc. 433 Email: dino@cisco.com 435 David Meyer 436 Cisco Systems, Inc. 438 Email: dmm@1-4-5.net 440 John Curran 441 ServerVault 443 Email: jcurran@istaff.org 445 Full Copyright Statement 447 Copyright (C) The IETF Trust (2007). 449 This document is subject to the rights, licenses and restrictions 450 contained in BCP 78, and except as set forth therein, the authors 451 retain all their rights. 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 457 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Intellectual Property 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Acknowledgment 487 Funding for the RFC Editor function is provided by the IETF 488 Administrative Support Activity (IASA).