idnits 2.17.00 (12 Aug 2021) /tmp/idnits38691/draft-boucadair-lisp-multiple-records-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2017) is 1679 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-boucadair-lisp-bulk-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Updates: 6830 (if approved) Orange 5 Intended status: Experimental October 8, 2017 6 Expires: April 11, 2018 8 Retrieving Multiple LISP Records 9 draft-boucadair-lisp-multiple-records-00 11 Abstract 13 This document extends Locator/ID Separation Protocol (LISP) with a 14 capability to retrieve multiple records using the same LISP request. 16 This document updates RFC6830. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 11, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Map-Request with Multiple Records . . . . . . . . . . . . . . 2 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7.1. Normative references . . . . . . . . . . . . . . . . . . 6 60 7.2. Informative references . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 66 upon a mapping mechanism that is used by ingress/egress Tunnel 67 Routers (xTR) to forward traffic over the LISP network. This 68 document extends LISP with a capability for bulk mappings retrieval. 69 It does so by defining new LISP messages that are meant to facilitate 70 state recovery of mapping tables and improve Ingress Tunnel Routers 71 (ITR) recovery times, in particular. 73 The base LISP specification does not define how a requestor may ask 74 for multiple EIDs. Indeed, the current LISP specification [RFC6830] 75 states the following: 77 Support for requesting multiple EIDs in a single Map-Request 78 message will be specified in a future version of the protocol. 80 The document defines a backward compatible extension of the LISP Map- 81 Request message to request multiple records (Section 3). 83 A more reliable method for bulk retrieval is defined in 84 [I-D.boucadair-lisp-bulk]. It does so by using TCP ([RFC0793]) as a 85 transport protocol for exchanges the bulk retrieval messages. 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. Map-Request with Multiple Records 95 As mentioned in Section 1, [RFC6830] does not specify how an ITR can 96 request for multiple EIDs using the same Map-Request message. This 97 document fills that void. 99 Figure 1 shows the difference between the Map-Request message format 100 as defined in [RFC6830] and the new format that includes the proposed 101 extension. This extension is meant to allow an ITR to request 102 multiple EID records by using the same Map-Request. 104 The proposed design is backward compatible since it aligns the 105 additional requested EID records at the end of the Map-Request 106 message. 108 As specified in [RFC6830], a mapping system must be prepared to 109 receive a request for multiple EID records in a Map-Request message. 110 A receiver relies upon the content of the "Record Count" field of the 111 Map-Request message to detect whether one or multiple records are 112 carried in the request. 114 OLD: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Nonce . . . | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | . . . Nonce | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Source-EID-AFI | Source EID Address ... | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | ... | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 / | Reserved | EID mask-len | EID-Prefix-AFI | 133 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 \ | EID-Prefix ... | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Map-Reply Record ... | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 NEW: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Nonce . . . | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | . . . Nonce | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Source-EID-AFI | Source EID Address ... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | ... | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 / | Reserved | EID mask-len | EID-Prefix-AFI | 158 Rec 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 \ | EID-Prefix ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Map-Reply Record ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 / | Reserved | EID mask-len | EID-Prefix-AFI | 164 Rec 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 \ | EID-Prefix ... | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 : ... : 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 / | Reserved | EID mask-len | EID-Prefix-AFI | 170 Rec m +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 \ | EID-Prefix ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1 176 The description of the fields of the updated Map-Request message is 177 exactly the same as in [RFC6830], except the additional records that 178 are prepended after the "Map-Reply Record" . The structure of a 179 record is exactly the same as in [RFC6830]. 181 When extracting the records included in a Map-Request message, a Map- 182 Resolver replies with the list of mappings that match these records. 183 One or multiple Map-Reply messages may be required to carry the 184 mapping records that match the requested EIDs included in a Map- 185 Request. 187 An ITR MUST be prepared to receive multiple Map-Reply messages from a 188 Map-Resolver as a response to a bulk Map-Request message that it 189 originally sent to that Map-Resolver. 191 In order to inform an ITR that subsequent Map-Reply messages will 192 follow (or not) , a dedicated flag bit is defined for this purpose: 193 it is called the M-bit (more-map-reply bit). 195 When set, the M-bit (more-map-reply bit) flag indicates this is not 196 the last Map-Reply message to be received by the requesting ITR; 197 additional Map-Reply messages follow. An implementation uses this 198 bit to decide when to terminate a request/response transaction. 200 If multiple Map-Reply messages are required to respond to a Map- 201 Request message, a Map-Resolver MUST set the M-bit flag for all Map- 202 Reply messages except for the last Map-Reply message. 204 OLD: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 |Type=2 |P|E|S| Reserved | Record Count | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Nonce . . . | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | . . . Nonce | 213 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | Record TTL | 215 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 R | Locator Count | EID mask-len | ACT |A| Reserved | 217 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 219 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 r | EID-Prefix | 221 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | /| Priority | Weight | M Priority | M Weight | 223 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | o | Unused Flags |L|p|R| Loc-AFI | 225 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | \| Locator | 227 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 NEW: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Type=2 |P|E|S|M| Reserved | Record Count | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Nonce . . . | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | . . . Nonce | 238 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | Record TTL | 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 R | Locator Count | EID mask-len | ACT |A| Reserved | 242 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 244 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 r | EID-Prefix | 246 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | /| Priority | Weight | M Priority | M Weight | 248 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | o | Unused Flags |L|p|R| Loc-AFI | 250 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | \| Locator | 252 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 4. Security Considerations 256 This document adheres to the security considerations discussed in 257 [RFC6830] and [RFC6833]. 259 5. IANA Considerations 261 This document does not require any IANA action. 263 6. Acknowledgments 265 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 266 009-X. 268 Many thanks to S. Secci and Chi Dung Phung for the comments. 270 7. References 272 7.1. Normative references 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 280 Locator/ID Separation Protocol (LISP)", RFC 6830, 281 DOI 10.17487/RFC6830, January 2013, 282 . 284 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 285 Protocol (LISP) Map-Server Interface", RFC 6833, 286 DOI 10.17487/RFC6833, January 2013, 287 . 289 7.2. Informative references 291 [I-D.boucadair-lisp-bulk] 292 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 293 Retrieval", draft-boucadair-lisp-bulk-05 (work in 294 progress), April 2017. 296 [I-D.ietf-tcpm-tcp-security] 297 Gont, F., "Survey of Security Hardening Methods for 298 Transmission Control Protocol (TCP) Implementations", 299 draft-ietf-tcpm-tcp-security-03 (work in progress), March 300 2012. 302 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 303 RFC 793, DOI 10.17487/RFC0793, September 1981, 304 . 306 Authors' Addresses 308 Mohamed Boucadair 309 Orange 310 Rennes 35000 311 France 313 EMail: mohamed.boucadair@orange.com 315 Christian Jacquenet 316 Orange 317 Rennes 35000 318 France 320 EMail: christian.jacquenet@orange.com