idnits 2.17.1 draft-ietf-lisp-lcaf-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '...is reserved for future use and MUST be...' RFC 2119 keyword, line 231: '...is reserved for future use and MUST be...' RFC 2119 keyword, line 619: '... See [LISP-MRSIG] for details. The J-bit MUST not be set when the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 'MUST not' in this paragraph: J-bit: this is the Join-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. The J-bit MUST not be set when the L-bit is also set in the same LCAF block. A receiver should not take any specific Join or Leave action when both bits are set. -- The document date (October 16, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-mr-signaling-03 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-03 == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-03 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-03 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental D. Meyer 5 Expires: April 19, 2015 Brocade 6 J. Snijders 7 Hibernia Networks 8 October 16, 2014 10 LISP Canonical Address Format (LCAF) 11 draft-ietf-lisp-lcaf-06 13 Abstract 15 This draft defines a canonical address format encoding used in LISP 16 control messages and in the encoding of lookup keys for the LISP 17 Mapping Database System. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 19, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 55 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 4 56 4. LISP Canonical Address Applications . . . . . . . . . . . . . 6 57 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 6 58 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 59 4.3. Convey Application Specific Data . . . . . . . . . . . . 9 60 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . 10 61 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . 11 62 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 63 4.7. PETR Admission Control Functionality . . . . . . . . . . 15 64 4.8. Multicast Group Membership Information . . . . . . . . . 16 65 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . 18 66 4.10. Storing Security Data in the Mapping Database . . . . . . 19 67 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20 68 4.12. Replication List Entries for Multicast Forwarding . . . . 21 69 4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22 70 4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . 23 71 4.15. Applications for AFI List Type . . . . . . . . . . . . . 23 72 4.15.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 23 73 4.15.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 25 74 4.15.3. ASCII Names in the Mapping Database . . . . . . . . 25 75 4.15.4. Using Recursive LISP Canonical Address Encodings . . 26 76 4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . 27 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 81 7.2. Informative References . . . . . . . . . . . . . . . . . 28 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 29 83 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 30 84 B.1. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 30 85 B.2. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 30 86 B.3. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 30 87 B.4. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 30 88 B.5. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 31 89 B.6. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 31 90 B.7. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 31 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 93 1. Introduction 95 The LISP architecture and protocols [RFC6830] introduces two new 96 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 97 (RLOCs) which are intended to replace most use of IP addresses on the 98 Internet. To provide flexibility for current and future 99 applications, these values can be encoded in LISP control messages 100 using a general syntax that includes Address Family Identifier (AFI), 101 length, and value fields. 103 Currently defined AFIs include IPv4 and IPv6 addresses, which are 104 formatted according to code-points assigned in [AFI] as follows: 106 IPv4 Encoded Address: 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | AFI = 1 | IPv4 Address ... | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | ... IPv4 Address | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 IPv6 Encoded Address: 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | AFI = 2 | IPv6 Address ... | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | ... IPv6 Address ... | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | ... IPv6 Address ... | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | ... IPv6 Address ... | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | ... IPv6 Address | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 This document describes the currently-defined AFIs the LISP protocol 133 uses along with their encodings and introduces the LISP Canonical 134 Address Format (LCAF) that can be used to define the LISP-specific 135 encodings for arbitrary AFI values. 137 2. Definition of Terms 139 Address Family Identifier (AFI): a term used to describe an address 140 encoding in a packet. An address family currently defined for 141 IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The 142 reserved AFI value of 0 is used in this specification to indicate 143 an unspecified encoded address where the the length of the address 144 is 0 bytes following the 16-bit AFI value of 0. 146 Unspecified Address Format: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | AFI = 0 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 155 used in the source and destination address fields of the first 156 (most inner) LISP header of a packet. The host obtains a 157 destination EID the same way it obtains a destination address 158 today, for example through a DNS lookup or SIP exchange. The 159 source EID is obtained via existing mechanisms used to set a 160 host's "local" IP address. An EID is allocated to a host from an 161 EID-prefix block associated with the site where the host is 162 located. An EID can be used by a host to refer to other hosts. 164 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 165 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 166 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 167 numbered from topologically aggregatable blocks that are assigned 168 to a site at each point to which it attaches to the global 169 Internet; where the topology is defined by the connectivity of 170 provider networks, RLOCs can be thought of as PA addresses. 171 Multiple RLOCs can be assigned to the same ETR device or to 172 multiple ETR devices at a site. 174 3. LISP Canonical Address Format Encodings 176 IANA has assigned AFI value 16387 (0x4003) to the LISP architecture 177 and protocols. This specification defines the encoding format of the 178 LISP Canonical Address (LCA). 180 The first 4 bytes of an LISP Canonical Address are followed by a 181 variable length of fields: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | AFI = 16387 | Rsvd1 | Flags | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Rsvd2 | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Rsvd1: this 8-bit field is reserved for future use and MUST be 192 transmitted as 0 and ignored on receipt. 194 Flags: this 8-bit field is for future definition and use. For now, 195 set to zero on transmission and ignored on receipt. 197 Type: this 8-bit field is specific to the LISP Canonical Address 198 formatted encodings, values are: 200 Type 0: Null Body Type 202 Type 1: AFI List Type 204 Type 2: Instance ID Type 206 Type 3: AS Number Type 208 Type 4: Application Data Type 210 Type 5: Geo Coordinates Type 212 Type 6: Opaque Key Type 214 Type 7: NAT-Traversal Type 216 Type 8: Nonce Locator Type 218 Type 9: Multicast Info Type 220 Type 10: Explicit Locator Path Type 222 Type 11: Security Key Type 224 Type 12: Source/Dest Key Type 226 Type 13: Replication List Entry Type 227 Type 14: JSON Data Model Type 229 Type 15: Key/Value Address Pair Type 231 Rsvd2: this 8-bit field is reserved for future use and MUST be 232 transmitted as 0 and ignored on receipt. 234 Length: this 16-bit field is in units of bytes and covers all of the 235 LISP Canonical Address payload, starting and including the byte 236 after the Length field. So any LCAF encoded address will have a 237 minimum length of 8 bytes when the Length field is 0. The 8 bytes 238 include the AFI, Flags, Type, Reserved, and Length fields. When 239 the AFI is not next to encoded address in a control message, then 240 the encoded address will have a minimum length of 6 bytes when the 241 Length field is 0. The 6 bytes include the Flags, Type, Reserved, 242 and Length fields. 244 [RFC6830] states RLOC records are sorted when encoded in control 245 messages so the locator-set has consistent order across all xTRs for 246 a given EID. The sort order is based on sort-key {afi, RLOC- 247 address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- 248 Type, payload}. Therefore, when a locator-set has a mix of AFI 249 records and LCAF records, all LCAF records will appear after all the 250 AFI records. 252 4. LISP Canonical Address Applications 254 4.1. Segmentation using LISP 256 When multiple organizations inside of a LISP site are using private 257 addresses [RFC1918] as EID-prefixes, their address spaces must remain 258 segregated due to possible address duplication. An Instance ID in 259 the address encoding can aid in making the entire AFI based address 260 unique. 262 Another use for the Instance ID LISP Canonical Address Format is when 263 creating multiple segmented VPNs inside of a LISP site where keeping 264 EID-prefix based subnets is desirable. 266 Instance ID LISP Canonical Address Format: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | AFI = 16387 | Rsvd1 | Flags | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type = 2 | IID mask-len | 4 + n | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Instance ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | AFI = x | Address ... | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 IID mask-len: if the AFI is set to 0, then this format is not 281 encoding an extended EID-prefix but rather an instance-ID range 282 where the 'IID mask-len' indicates the number of high-order bits 283 used in the Instance ID field for the range. 285 Length value n: length in bytes of the AFI address that follows the 286 Instance ID field including the AFI field itself. 288 Instance ID: the low-order 24-bits that can go into a LISP data 289 header when the I-bit is set. See [RFC6830] for details. 291 AFI = x: x can be any AFI value from [AFI]. 293 This LISP Canonical Address Type can be used to encode either EID or 294 RLOC addresses. 296 4.2. Carrying AS Numbers in the Mapping Database 298 When an AS number is stored in the LISP Mapping Database System for 299 either policy or documentation reasons, it can be encoded in a LISP 300 Canonical Address. 302 AS Number LISP Canonical Address Format: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | AFI = 16387 | Rsvd1 | Flags | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type = 3 | Rsvd2 | 4 + n | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | AS Number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | AFI = x | Address ... | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Length value n: length in bytes of the AFI address that follows the 317 AS Number field including the AFI field itself. 319 AS Number: the 32-bit AS number of the autonomous system that has 320 been assigned either the EID or RLOC that follows. 322 AFI = x: x can be any AFI value from [AFI]. 324 The AS Number Canonical Address Type can be used to encode either EID 325 or RLOC addresses. The former is used to describe the LISP-ALT AS 326 number the EID-prefix for the site is being carried for. The latter 327 is used to describe the AS that is carrying RLOC based prefixes in 328 the underlying routing system. 330 4.3. Convey Application Specific Data 332 When a locator-set needs to be conveyed based on the type of 333 application or the Per-Hop Behavior (PHB) of a packet, the 334 Application Data Type can be used. 336 Application Data LISP Canonical Address Format: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | AFI = 16387 | Rsvd1 | Flags | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type = 4 | Rsvd2 | 8 + n | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | IP TOS, IPv6 TC, or Flow Label | Protocol | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Local Port (lower-range) | Local Port (upper-range) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Remote Port (lower-range) | Remote Port (upper-range) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | AFI = x | Address ... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Length value n: length in bytes of the AFI address that follows the 355 8-byte Application Data fields including the AFI field itself. 357 IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS 358 field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow 359 Label used in an IPv6 header. 361 Local Port/Remote Port Ranges: these fields are from the TCP, UDP, 362 or SCTP transport header. A range can be specified by using a 363 lower value and an upper value. When a single port is encoded, 364 the lower and upper value fields are the same. 366 AFI = x: x can be any AFI value from [AFI]. 368 The Application Data Canonical Address Type is used for an EID 369 encoding when an ITR wants a locator-set for a specific application. 370 When used for an RLOC encoding, the ETR is supplying a locator-set 371 for each specific application is has been configured to advertise. 373 4.4. Assigning Geo Coordinates to Locator Addresses 375 If an ETR desires to send a Map-Reply describing the Geo Coordinates 376 for each locator in its locator-set, it can use the Geo Coordinate 377 Type to convey physical location information. 379 Coordinates are specified using the WGS-84 (World Geodetic System) 380 reference coordinate system [WGS-84]. 382 Geo Coordinate LISP Canonical Address Format: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | AFI = 16387 | Rsvd1 | Flags | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type = 5 | Rsvd2 | 12 + n | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |N| Latitude Degrees | Minutes | Seconds | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |E| Longitude Degrees | Minutes | Seconds | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Altitude | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | AFI = x | Address ... | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Length value n: length in bytes of the AFI address that follows the 401 8-byte Longitude and Latitude fields including the AFI field 402 itself. 404 N: When set to 1 means North, otherwise South. 406 Latitude Degrees: Valid values range from 0 to 90 degrees above or 407 below the equator (northern or southern hemisphere, respectively). 409 Latitude Minutes: Valid values range from 0 to 59. 411 Latitude Seconds: Valid values range from 0 to 59. 413 E: When set to 1 means East, otherwise West. 415 Longitude Degrees: Value values are from 0 to 180 degrees right or 416 left of the Prime Meridian. 418 Longitude Minutes: Valid values range from 0 to 59. 420 Longitude Seconds: Valid values range from 0 to 59. 422 Altitude: Height relative to sea level in meters. This is a signed 423 integer meaning that the altitude could be below sea level. A 424 value of 0x7fffffff indicates no Altitude value is encoded. 426 AFI = x: x can be any AFI value from [AFI]. 428 The Geo Coordinates Canonical Address Type can be used to encode 429 either EID or RLOC addresses. When used for EID encodings, you can 430 determine the physical location of an EID along with the topological 431 location by observing the locator-set. 433 4.5. Generic Database Mapping Lookups 435 When the LISP Mapping Database system holds information accessed by a 436 generic formatted key (where the key is not the usual IPv4 or IPv6 437 address), an opaque key may be desirable. 439 Opaque Key LISP Canonical Address Format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | AFI = 16387 | Rsvd1 | Flags | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type = 6 | Rsvd2 | n | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Key Field Num | Key Wildcard Fields | Key . . . | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | . . . Key | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Length value n: length in bytes of the type's payload. The value n 454 is the number of bytes that follow this Length field. 456 Key Field Num: the number of fields (minus 1) the key can be broken 457 up into. The width of the fields are fixed length. So for a key 458 size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 459 bytes in length. Valid values for this field range from 0 to 15 460 supporting a maximum of 16 field separations. 462 Key Wildcard Fields: describes which fields in the key are not used 463 as part of the key lookup. This wildcard encoding is a bitfield. 464 Each bit is a don't-care bit for a corresponding field in the key. 465 Bit 0 (the low-order bit) in this bitfield corresponds the first 466 field, right-justified in the key, bit 1 the second field, and so 467 on. When a bit is set in the bitfield it is a don't-care bit and 468 should not be considered as part of the database lookup. When the 469 entire 16-bits is set to 0, then all bits of the key are used for 470 the database lookup. 472 Key: the variable length key used to do a LISP Database Mapping 473 lookup. The length of the key is the value n (shown above) minus 474 3. 476 4.6. NAT Traversal Scenarios 478 When a LISP system is conveying global address and mapped port 479 information when traversing through a NAT device, the NAT-Traversal 480 LCAF Type is used. See [LISP-NATT] for details. 482 NAT-Traversal Canonical Address Format: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | AFI = 16387 | Rsvd1 | Flags | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = 7 | Rsvd2 | 4 + n | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | MS UDP Port Number | ETR UDP Port Number | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | AFI = x | Global ETR RLOC Address ... | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | AFI = x | MS RLOC Address ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | AFI = x | Private ETR RLOC Address ... | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | AFI = x | RTR RLOC Address 1 ... | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | AFI = x | RTR RLOC Address k ... | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Length value n: length in bytes of the AFI addresses that follows 505 the UDP Port Number field including the AFI fields themselves. 507 MS UDP Port Number: this is the UDP port number of the Map-Server 508 and is set to 4342. 510 ETR UDP Port Number: this is the port number returned to a LISP 511 system which was copied from the source port from a packet that 512 has flowed through a NAT device. 514 AFI = x: x can be any AFI value from [AFI]. 516 Global ETR RLOC Address: this is an address known to be globally 517 unique built by NAT-traversal functionality in a LISP router. 519 MS RLOC Address: this is the address of the Map-Server used in the 520 destination RLOC of a packet that has flowed through a NAT device. 522 Private ETR RLOC Address: this is an address known to be a private 523 address inserted in this LCAF format by a LISP router that resides 524 on the private side of a NAT device. 526 RTR RLOC Address: this is an encapsulation address used by an ITR or 527 PITR which resides behind a NAT device. This address is known to 528 have state in a NAT device so packets can flow from it to the LISP 529 ETR behind the NAT. There can be one or more NTR addresses 530 supplied in these set of fields. The number of NTRs encoded is 531 determined by the LCAF length field. When there are no NTRs 532 supplied, the NTR fields can be omitted and reflected by the LCAF 533 length field or an AFI of 0 can be used to indicate zero NTRs 534 encoded. 536 4.7. PETR Admission Control Functionality 538 When a public PETR device wants to verify who is encapsulating to it, 539 it can check for a specific nonce value in the LISP encapsulated 540 packet. To convey the nonce to admitted ITRs or PITRs, this LCAF 541 format is used in a Map-Register or Map-Reply locator-record. 543 Nonce Locator Canonical Address Format: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | AFI = 16387 | Rsvd1 | Flags | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type = 8 | Rsvd2 | 4 + n | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Reserved | Nonce | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | AFI = x | Address ... | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Length value n: length in bytes of the AFI address that follows the 558 Nonce field including the AFI field itself. 560 Reserved: must be set to zero and ignore on receipt. 562 Nonce: this is a nonce value returned by an ETR in a Map-Reply 563 locator-record to be used by an ITR or PITR when encapsulating to 564 the locator address encoded in the AFI field of this LCAF type. 566 AFI = x: x can be any AFI value from [AFI]. 568 4.8. Multicast Group Membership Information 570 Multicast group information can be published in the mapping database 571 so a lookup on an EID based group address can return a replication 572 list of group addresses or a unicast addresses for single replication 573 or multiple head-end replications. The intent of this type of 574 unicast replication is to deliver packets to multiple ETRs at 575 receiver LISP multicast sites. The locator-set encoding for this EID 576 record type can be a list of ETRs when they each register with "Merge 577 Semantics". The encoding can be a typical AFI encoded locator 578 address. When an RTR list is being registered (with multiple levels 579 according to [LISP-RE]), the Replication List Entry LCAF type is used 580 for locator encoding. 582 This LCAF encoding can be used to send broadcast packets to all 583 members of a subnet when each EIDs are away from their home subnet 584 location. 586 Multicast Info Canonical Address Format: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | AFI = 16387 | Rsvd1 | Flags | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type = 9 | Rsvd2 |R|L|J| 8 + n | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Instance-ID | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reserved | Source MaskLen| Group MaskLen | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | AFI = x | Source/Subnet Address ... | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | AFI = x | Group Address ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Length value n: length in bytes of fields that follow. 606 Reserved: must be set to zero and ignore on receipt. 608 R-bit: this is the RP-bit that represents PIM (S,G,RP-bit) multicast 609 state. This bit can be set for Joins (when the J-bit is set) or 610 for Leaves (when the L-bit is set). See [LISP-MRSIG] for more 611 usage details. 613 L-bit: this is the Leave-Request bit and is used when this LCAF type 614 is present in the destination EID-prefix field of a Map-Request. 615 See [LISP-MRSIG] for details. 617 J-bit: this is the Join-Request bit and is used when this LCAF type 618 is present in the destination EID-prefix field of a Map-Request. 619 See [LISP-MRSIG] for details. The J-bit MUST not be set when the 620 L-bit is also set in the same LCAF block. A receiver should not 621 take any specific Join or Leave action when both bits are set. 623 Instance ID: the low-order 24-bits that can go into a LISP data 624 header when the I-bit is set. See [RFC6830] for details. The use 625 of the Instance-ID in this LCAF type is to associate a multicast 626 forwarding entry for a given VPN. The instance-ID describes the 627 VPN and is registered to the mapping database system as a 3-tuple 628 of (Instance-ID, S-prefix, G-prefix). 630 Source MaskLen: the mask length of the source prefix that follows. 632 Group MaskLen: the mask length of the group prefix that follows. 634 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has 635 its own encoding of a multicast address, this field must be either 636 a group address or a broadcast address. 638 4.9. Traffic Engineering using Re-encapsulating Tunnels 640 For a given EID lookup into the mapping database, this LCAF format 641 can be returned to provide a list of locators in an explicit re- 642 encapsulation path. See [LISP-TE] for details. 644 Explicit Locator Path (ELP) Canonical Address Format: 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | AFI = 16387 | Rsvd1 | Flags | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type = 10 | Rsvd2 | n | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Rsvd3 |L|P|S| AFI = x | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Reencap Hop 1 ... | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Rsvd3 |L|P|S| AFI = x | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Reencap Hop k ... | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Length value n: length in bytes of fields that follow. 664 Lookup bit (L): this is the Lookup bit used to indicate to the user 665 of the ELP to not use this address for encapsulation but to look 666 it up in the mapping database system to obtain an encapsulating 667 RLOC address. 669 RLOC-Probe bit (P): this is the RLOC-probe bit which means the 670 Reencap Hop allows RLOC-probe messages to be sent to it. When the 671 R-bit is set to 0, RLOC-probes must not be sent. When a Reencap 672 Hop is an anycast address then multiple physical Reencap Hops are 673 using the same RLOC address. In this case, RLOC-probes are not 674 needed because when the closest RLOC address is not reachable 675 another RLOC address can reachable. 677 Strict bit (S): this the strict bit which means the associated 678 Rencap Hop is required to be used. If this bit is 0, the 679 reencapsulator can skip this Reencap Hop and go to the next one in 680 the list. 682 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has 683 its own encoding of a multicast address, this field must be either 684 a group address or a broadcast address. 686 4.10. Storing Security Data in the Mapping Database 688 When a locator in a locator-set has a security key associated with 689 it, this LCAF format will be used to encode key material. See 690 [LISP-DDT] for details. 692 Security Key Canonical Address Format: 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | AFI = 16387 | Rsvd1 | Flags | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type = 11 | Rsvd2 | 6 + n | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Key Length | Key Material ... | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | ... Key Material | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | AFI = x | Locator Address ... | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Length value n: length in bytes of fields that start with the Key 711 Material field. 713 Key Count: the Key Count field declares the number of Key sections 714 included in this LCAF. 716 Key Algorithm: the Algorithm field identifies the key's 717 cryptographic algorithm and specifies the format of the Public Key 718 field. 720 R bit: this is the revoke bit and, if set, it specifies that this 721 Key is being Revoked. 723 Key Length: this field determines the length in bytes of the Key 724 Material field. 726 Key Material: the Key Material field stores the key material. The 727 format of the key material stored depends on the Key Algorithm 728 field. 730 AFI = x: x can be any AFI value from [AFI].This is the locator 731 address that owns the encoded security key. 733 4.11. Source/Destination 2-Tuple Lookups 735 When both a source and destination address of a flow needs 736 consideration for different locator-sets, this 2-tuple key is used in 737 EID fields in LISP control messages. When the Source/Dest key is 738 registered to the mapping database, it can be encoded as a source- 739 prefix and destination-prefix. When the Source/Dest is used as a key 740 for a mapping database lookup the source and destination come from a 741 data packet. 743 Source/Dest Key Canonical Address Format: 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | AFI = 16387 | Rsvd1 | Flags | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Type = 12 | Rsvd2 | 4 + n | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Reserved | Source-ML | Dest-ML | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | AFI = x | Source-Prefix ... | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | AFI = x | Destination-Prefix ... | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Length value n: length in bytes of fields that follow. 761 Reserved: must be set to zero and ignore on receipt. 763 Source-ML: the mask length of the source prefix that follows. 765 Dest-ML: the mask length of the destination prefix that follows. 767 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has 768 its own encoding of a multicast address, this field must be either 769 a group address or a broadcast address. 771 Refer to [LISP-TE] for usage details. 773 4.12. Replication List Entries for Multicast Forwarding 775 The Replication List Entry LCAF type is an encoding for a locator 776 being used for unicast replication according to the specification in 777 [LISP-RE]. This locator encoding is pointed to by a Multicast Info 778 LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) 779 that are participating in an overlay distribution tree. Each RTR 780 will register its locator address and its configured level in the 781 distribution tree. 783 Replication List Entry Address Format: 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | AFI = 16387 | Rsvd1 | Flags | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type = 13 | Rsvd2 | 4 + n | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Rsvd3 | Rsvd4 | Level Value | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | AFI = x | RTR/ETR #1 ... | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Rsvd3 | Rsvd4 | Level Value | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | AFI = x | RTR/ETR #n ... | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 Length value n: length in bytes of fields that follow. 803 Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. 805 Level Value: this value is associated with the level within the 806 overlay distribution tree hierarchy where the RTR resides. The 807 level numbers are ordered from lowest value being close to the ITR 808 (meaning that ITRs replicate to level-0 RTRs) and higher levels 809 are further downstream on the distribution tree closer to ETRs of 810 multicast receiver sites. 812 AFI = x: x can be any AFI value from [AFI]. A specific AFI has its 813 own encoding of either a unicast or multicast locator address. 814 All RTR/ETR entries for the same level should be combined together 815 by a Map-Server to avoid searching through the entire multi-level 816 list of locator entries in a Map-Reply message. 818 4.13. Data Model Encoding 820 This type allows a JSON data model to be encoded either as an EID or 821 RLOC. 823 JSON Data Model Type Address Format: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | AFI = 16387 | Rsvd1 | Flags | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Type = 14 | Rsvd2 |B| n | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | JSON length | JSON binary/text encoding ... | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | AFI = x | Optional Address ... | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Length value n: length in bytes of fields that follow. 839 Rsvd{1,2}: must be set to zero and ignore on receipt. 841 B bit: indicates that the JSON field is binary encoded according to 842 [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is 843 based on text encoding according to [RFC4627]. 845 JSON length: length in octets of the following 'JSON binary/text 846 encoding' field. 848 JSON binary/text encoding field: a variable length field that 849 contains either binary or text encodings. 851 AFI = x: x can be any AFI value from [AFI]. A specific AFI has its 852 own encoding of either a unicast or multicast locator address. 853 All RTR/ETR entries for the same level should be combined together 854 by a Map-Server to avoid searching through the entire multi-level 855 list of locator entries in a Map-Reply message. 857 4.14. Encoding Key/Value Address Pairs 859 The Key/Value pair is for example useful for attaching attributes to 860 other elements of LISP packets, such as EIDs or RLOCs. When 861 attaching attributes to EIDs or RLOCs, it's necessary to distinguish 862 between the element that should be used as EID or RLOC, and hence as 863 key for lookups, and additional attributes. This is especially the 864 case when the difference cannot be determined from the types of the 865 elements, such as when two IP addresses are being used. 867 Key/Value Pair Address Format: 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | AFI = 16387 | Rsvd1 | Flags | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Type = 15 | Rsvd2 | n | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | AFI = x | Address as Key ... | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | AFI = x | Address as Value ... | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Length value n: length in bytes of fields that follow. 883 Rsvd{1,2}: must be set to zero and ignore on receipt. 885 AFI = x: x can be any AFI value from [AFI]. A specific AFI has its 886 own encoding of either a unicast or multicast locator address. 887 All RTR/ETR entries for the same level should be combined together 888 by a Map-Server to avoid searching through the entire multi-level 889 list of locator entries in a Map-Reply message. 891 Address as Key: this AFI encoded address will be attached with the 892 attributes encoded in "Address as Value" which follows this field. 894 Address as Value: this AFI encoded address will be the attribute 895 address that goes along with "Address as Key" which precedes this 896 field. 898 4.15. Applications for AFI List Type 900 4.15.1. Binding IPv4 and IPv6 Addresses 902 When header translation between IPv4 and IPv6 is desirable a LISP 903 Canonical Address can use the AFI List Type to carry multiple AFIs in 904 one LCAF AFI. 906 Address Binding LISP Canonical Address Format: 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | AFI = 16387 | Rsvd1 | Flags | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | AFI = 1 | IPv4 Address ... | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | ... IPv4 Address | AFI = 2 | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | IPv6 Address ... | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | ... IPv6 Address ... | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | ... IPv6 Address ... | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | ... IPv6 Address | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI 929 encoded addresses are used. 931 This type of address format can be included in a Map-Request when the 932 address is being used as an EID, but the Mapping Database System 933 lookup destination can use only the IPv4 address. This is so a 934 Mapping Database Service Transport System, such as LISP-ALT 935 [RFC6836], can use the Map-Request destination address to route the 936 control message to the desired LISP site. 938 4.15.2. Layer-2 VPNs 940 When MAC addresses are stored in the LISP Mapping Database System, 941 the AFI List Type can be used to carry AFI 6. 943 MAC Address LISP Canonical Address Format: 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | AFI = 16387 | Rsvd1 | Flags | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Type = 1 | Rsvd2 | 2 + 6 | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | AFI = 6 | Layer-2 MAC Address ... | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | ... Layer-2 MAC Address | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Length: length in bytes is fixed at 8 when MAC address AFI encoded 958 addresses are used. 960 This address format can be used to connect layer-2 domains together 961 using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. 962 In this use-case, a MAC address is being used as an EID, and the 963 locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or 964 even another MAC address being used as an RLOC. 966 4.15.3. ASCII Names in the Mapping Database 968 If DNS names or URIs are stored in the LISP Mapping Database System, 969 the AFI List Type can be used to carry an ASCII string where it is 970 delimited by length 'n' of the LCAF Length encoding. 972 ASCII LISP Canonical Address Format: 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | AFI = 16387 | Rsvd1 | Flags | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Type = 1 | Rsvd2 | 2 + n | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | AFI = 17 | DNS Name or URI ... | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Length value n: length in bytes AFI=17 field and the null-terminated 985 ASCII string (the last byte of 0 is included). 987 4.15.4. Using Recursive LISP Canonical Address Encodings 989 When any combination of above is desirable, the AFI List Type value 990 can be used to carry within the LCAF AFI another LCAF AFI. 992 Recursive LISP Canonical Address Format: 994 0 1 2 3 995 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 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | AFI = 16387 | Rsvd1 | Flags | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | AFI = 16387 | Rsvd1 | Flags | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Type = 4 | Rsvd2 | 12 | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | IP TOS, IPv6 QQS or Flow Label | Protocol | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Local Port | Remote Port | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | AFI = 1 | IPv4 Address ... | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | ... IPv4 Address | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is 1015 included. 1017 This format could be used by a Mapping Database Transport System, 1018 such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as 1019 an EID and placed in the Map-Request destination address by the 1020 sending LISP system. The ALT system can deliver the Map-Request to 1021 the LISP destination site independent of the Application Data Type 1022 AFI payload values. When this AFI is processed by the destination 1023 LISP site, it can return different locator-sets based on the type of 1024 application or level of service that is being requested. 1026 4.15.5. Compatibility Mode Use Case 1028 A LISP system should use the AFI List Type format when sending to 1029 LISP systems that do not support a particular LCAF Type used to 1030 encode locators. This allows the receiving system to be able to 1031 parse a locator address for encapsulation purposes. The list of AFIs 1032 in an AFI List LCAF Type has no semantic ordering and a receiver 1033 should parse each AFI element no matter what the ordering. 1035 Compatibility Mode Address Format: 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | AFI = 16387 | Rsvd1 | Flags | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Type = 1 | Rsvd2 | 22 + 6 | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | AFI = 16387 | Rsvd1 | Flags | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Type = 5 | Rsvd2 | 12 + 2 | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |N| Latitude Degrees | Minutes | Seconds | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 |E| Longitude Degrees | Minutes | Seconds | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Altitude | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | AFI = 0 | AFI = 1 | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | IPv4 Address | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 If a system does not recognized the Geo Coordinate LCAF Type that is 1060 accompanying a locator address, an encoder can include the Geo 1061 Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI 1062 in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in 1063 the list is encoded with a valid AFI value to identify the locator 1064 address. 1066 A LISP system is required to support the AFI List LCAF Type to use 1067 this procedure. It would skip over 10 bytes of the Geo Coordinate 1068 LCAF Type to get to the locator address encoding (an IPv4 locator 1069 address). A LISP system that does support the Geo Coordinate LCAF 1070 Type can support parsing the locator address within the Geo 1071 Coordinate LCAF encoding or in the locator encoding that follows in 1072 the AFI List LCAF. 1074 5. Security Considerations 1076 There are no security considerations for this specification. The 1077 security considerations are documented for the protocols that use 1078 LISP Canonical Addressing. Refer to the those relevant 1079 specifications. 1081 6. IANA Considerations 1083 The Address Family AFI definitions from [AFI] only allocate code- 1084 points for the AFI value itself. The length of the address or entity 1085 that follows is not defined and is implied based on conventional 1086 experience. Where the LISP protocol uses LISP Canonical Addresses 1087 specifically, the address length definitions will be in this 1088 specification and take precedent over any other specification. 1090 An IANA Registry for LCAF Type values will be created. The values 1091 that are considered for use by the main LISP specification [RFC6830] 1092 will be in the IANA Registry. Other Type values used for 1093 experimentation will be defined and described in this document. 1095 7. References 1097 7.1. Normative References 1099 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1100 October 1994. 1102 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1103 E. Lear, "Address Allocation for Private Internets", BCP 1104 5, RFC 1918, February 1996. 1106 [RFC4627] Crockford, D., "The application/json Media Type for 1107 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1109 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1110 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1111 2013. 1113 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1114 "Locator/ID Separation Protocol Alternative Logical 1115 Topology (LISP+ALT)", RFC 6836, January 2013. 1117 7.2. Informative References 1119 [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY 1120 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 1122 [JSON-BINARY] 1123 "Universal Binary JSON Specification", URL 1124 http://ubjson.org, . 1126 [LISP-DDT] 1127 Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated 1128 Database Tree", draft-ietf-lisp-ddt-01.txt (work in 1129 progress), . 1131 [LISP-MRSIG] 1132 Farinacci, D. and M. Napierala, "LISP Control-Plane 1133 Multicast Signaling", draft-farinacci-lisp-mr-signaling- 1134 03.txt (work in progress), . 1136 [LISP-NATT] 1137 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 1138 F., and C. White, "NAT traversal for LISP", draft-ermagan- 1139 lisp-nat-traversal-03.txt (work in progress), . 1141 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 1142 Maino, F., and D. Farinacci, "LISP Replication 1143 Engineering", draft-coras-lisp-re-03.txt (work in 1144 progress), . 1146 [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 1147 Engineering Use-Cases", draft-farinacci-lisp-te-03.txt 1148 (work in progress), . 1150 [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic 1151 System 1984", NIMA TR8350.2, January 2000, . 1154 Appendix A. Acknowledgments 1156 The authors would like to thank Vince Fuller, Gregg Schudel, Jesper 1157 Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for 1158 their technical and editorial commentary. 1160 The authors would like to thank Victor Moreno for discussions that 1161 lead to the definition of the Multicast Info LCAF type. 1163 The authors would like to thank Parantap Lahiri and Michael Kowal for 1164 discussions that lead to the definition of the Explicit Locator Path 1165 (ELP) LCAF type. 1167 The authors would like to thank Fabio Maino and Vina Ermagan for 1168 discussions that lead to the definition of the Security Key LCAF 1169 type. 1171 The authors would like to thank Albert Cabellos-Aparicio and Florin 1172 Coras for discussions that lead to the definition of the Replication 1173 List Entry LCAF type. 1175 Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for 1176 suggesting new LCAF types. 1178 Thanks also goes to Terry Manderson for assistance obtaining a LISP 1179 AFI value from IANA. 1181 Appendix B. Document Change Log 1183 B.1. Changes to draft-ietf-lisp-lcaf-06.txt 1185 o Submitted October 2014. 1187 o Make it clear how sorted RLOC records are done when LCAFs are used 1188 as the RLOC record. 1190 B.2. Changes to draft-ietf-lisp-lcaf-05.txt 1192 o Submitted May 2014. 1194 o Add a length field of the JSON payload that can be used for either 1195 binary or text encoding of JSON data. 1197 B.3. Changes to draft-ietf-lisp-lcaf-04.txt 1199 o Submitted January 2014. 1201 o Agreement among ELP implementors to have the AFI 16-bit field 1202 adjacent to the address. This will make the encoding consistent 1203 with all other LCAF type address encodings. 1205 B.4. Changes to draft-ietf-lisp-lcaf-03.txt 1207 o Submitted September 2013. 1209 o Updated references and author's affilations. 1211 o Added Instance-ID to the Multicast Info Type so there is relative 1212 ease in parsing (S,G) entries within a VPN. 1214 o Add port range encodings to the Application Data LCAF Type. 1216 o Add a new JSON LCAF Type. 1218 o Add Address Key/Value LCAF Type to allow attributes to be attached 1219 to an address. 1221 B.5. Changes to draft-ietf-lisp-lcaf-02.txt 1223 o Submitted March 2013. 1225 o Added new LCAF Type "Replication List Entry" to support LISP 1226 replication engineering use-cases. 1228 o Changed references to new LISP RFCs. 1230 B.6. Changes to draft-ietf-lisp-lcaf-01.txt 1232 o Submitted January 2013. 1234 o Change longitude range from 0-90 to 0-180 in section 4.4. 1236 o Added reference to WGS-84 in section 4.4. 1238 B.7. Changes to draft-ietf-lisp-lcaf-00.txt 1240 o Posted first working group draft August 2012. 1242 o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. 1244 Authors' Addresses 1246 Dino Farinacci 1247 lispers.net 1248 San Jose, CA 1249 USA 1251 Email: farinacci@gmail.com 1253 Dave Meyer 1254 Brocade 1255 San Jose, CA 1256 USA 1258 Email: dmm@1-4-5.net 1259 Job Snijders 1260 Hibernia Networks 1261 Tupolevlaan 103a 1262 Schiphol-Rijk 1119 PA 1263 NL 1265 Email: job.snijders@hibernianetworks.com