idnits 2.17.1 draft-farinacci-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 177: '...is reserved for future use and MUST be...' RFC 2119 keyword, line 209: '...is reserved for future use and MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 459 has weird spacing: '... Number this ...' -- The document date (October 24, 2011) is 4573 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-06 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-12 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-00 Summary: 2 errors (**), 0 flaws (~~), 5 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 D. Meyer 4 Intended status: Experimental cisco Systems 5 Expires: April 26, 2012 J. Snijders 6 InTouch N.V. 7 October 24, 2011 9 LISP Canonical Address Format (LCAF) 10 draft-farinacci-lisp-lcaf-06 12 Abstract 14 This draft defines a canonical address format encoding used in LISP 15 control messages and in the encoding of lookup keys for the LISP 16 Mapping Database System. 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 http://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 26, 2012. 35 Copyright Notice 37 Copyright (c) 2011 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 54 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 55 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 56 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 57 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 58 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 59 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 60 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 11 61 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 62 4.7. PETR Admission Control Functionality . . . . . . . . . . . 14 63 4.8. Multicast Group Membership Information . . . . . . . . . . 15 64 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 17 65 4.10. Storing Security Data in the Mapping Database . . . . . . 18 66 4.11. Applications for AFI List Type . . . . . . . . . . . . . . 19 67 4.11.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 19 68 4.11.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 21 69 4.11.3. ASCII Names in the Mapping Database . . . . . . . . . 21 70 4.11.4. Using Recursive LISP Canonical Address Encodings . . 22 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 79 1. Introduction 81 The LISP architecture and protocols [LISP] introduces two new 82 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 83 (RLOCs) which are intended to replace most use of IP addresses on the 84 Internet. To provide flexibility for current and future 85 applications, these values can be encoded in LISP control messages 86 using a general syntax that includes Address Family Identifier (AFI), 87 length, and value fields. 89 Currently defined AFIs include IPv4 and IPv6 addresses, which are 90 formatted according to code-points assigned in [AFI] as follows: 92 IPv4 Encoded Address: 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | AFI = 1 | IPv4 Address ... | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | ... IPv4 Address | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 IPv6 Encoded Address: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | AFI = 2 | IPv6 Address ... | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | ... IPv6 Address ... | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | ... IPv6 Address ... | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | ... IPv6 Address ... | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | ... IPv6 Address | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 This document describes the currently-defined AFIs the LISP protocol 119 uses along with their encodings and introduces the LISP Canonical 120 Address Format (LCAF) that can be used to define the LISP-specific 121 encodings for arbitrary AFI values. 123 2. Definition of Terms 125 Address Family Identifier (AFI): a term used to describe an address 126 encoding in a packet. An address family currently defined for 127 IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The 128 reserved AFI value of 0 is used in this specification to indicate 129 an unspecified encoded address where the the length of the address 130 is 0 bytes following the 16-bit AFI value of 0. 132 Unspecified Address Format: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | AFI = 0 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 141 used in the source and destination address fields of the first 142 (most inner) LISP header of a packet. The host obtains a 143 destination EID the same way it obtains a destination address 144 today, for example through a DNS lookup or SIP exchange. The 145 source EID is obtained via existing mechanisms used to set a 146 host's "local" IP address. An EID is allocated to a host from an 147 EID-prefix block associated with the site where the host is 148 located. An EID can be used by a host to refer to other hosts. 150 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 151 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 152 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 153 numbered from topologically aggregatable blocks that are assigned 154 to a site at each point to which it attaches to the global 155 Internet; where the topology is defined by the connectivity of 156 provider networks, RLOCs can be thought of as PA addresses. 157 Multiple RLOCs can be assigned to the same ETR device or to 158 multiple ETR devices at a site. 160 3. LISP Canonical Address Format Encodings 162 IANA has assigned AFI value 16387 (0x4003) to the LISP architecture 163 and protocols. This specification defines the encoding format of the 164 LISP Canonical Address (LCA). 166 The first 4 bytes of an LISP Canonical Address are followed by a 167 variable length of fields: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | AFI = 16387 | Rsvd1 | Flags | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Rsvd2 | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Rsvd1: this 8-bit field is reserved for future use and MUST be 178 transmitted as 0 and ignored on receipt. 180 Flags: this 8-bit field is for future definition and use. For now, 181 set to zero on transmission and ignored on receipt. 183 Type: this 8-bit field is specific to the LISP Canonical Address 184 formatted encodings, values are: 186 Type 0: Null Body Type 188 Type 1: AFI List Type 190 Type 2: Instance ID Type 192 Type 3: AS Number Type 194 Type 4: Application Data Type 196 Type 5: Geo Coordinates Type 198 Type 6: Opaque Key Type 200 Type 7: NAT-Traversal Type 202 Type 8: Nonce Locator Type 204 Type 9: Multicast Info Type 205 Type 10: Explicit Locator Path Type 207 Type 11: Security Key Type 209 Rsvd2: this 8-bit field is reserved for future use and MUST be 210 transmitted as 0 and ignored on receipt. 212 Length: this 16-bit field is in units of bytes and covers all of the 213 LISP Canonical Address payload, starting and including the byte 214 after the Length field. So any LCAF encoded address will have a 215 minimum length of 8 bytes when the Length field is 0. The 8 bytes 216 include the AFI, Flags, Type, Reserved, and Length fields. When 217 the AFI is not next to encoded address in a control message, then 218 the encoded address will have a minimum length of 6 bytes when the 219 Length field is 0. The 6 bytes include the Flags, Type, Reserved, 220 and Length fields. 222 4. LISP Canonical Address Applications 224 4.1. Segmentation using LISP 226 When multiple organizations inside of a LISP site are using private 227 addresses [RFC1918] as EID-prefixes, their address spaces must remain 228 segregated due to possible address duplication. An Instance ID in 229 the address encoding can aid in making the entire AFI based address 230 unique. 232 Another use for the Instance ID LISP Canonical Address Format is when 233 creating multiple segmented VPNs inside of a LISP site where keeping 234 EID-prefix based subnets is desirable. 236 Instance ID LISP Canonical Address Format: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | AFI = 16387 | Rsvd1 | Flags | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type = 2 | Rsvd2 | 4 + n | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Instance ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | AFI = x | Address ... | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Length value n: length in bytes of the AFI address that follows the 251 Instance ID field including the AFI field itself. 253 Instance ID: the low-order 24-bits that can go into a LISP data 254 header when the I-bit is set. See [LISP] for details. 256 AFI = x: x can be any AFI value from [AFI]. 258 This LISP Canonical Address Type can be used to encode either EID or 259 RLOC addresses. 261 4.2. Carrying AS Numbers in the Mapping Database 263 When an AS number is stored in the LISP Mapping Database System for 264 either policy or documentation reasons, it can be encoded in a LISP 265 Canonical Address. 267 AS Number LISP Canonical Address Format: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AFI = 16387 | Rsvd1 | Flags | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type = 3 | Rsvd2 | 4 + n | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | AS Number | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | AFI = x | Address ... | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Length value n: length in bytes of the AFI address that follows the 282 AS Number field including the AFI field itself. 284 AS Number: the 32-bit AS number of the autonomous system that has 285 been assigned either the EID or RLOC that follows. 287 AFI = x: x can be any AFI value from [AFI]. 289 The AS Number Canonical Address Type can be used to encode either EID 290 or RLOC addresses. The former is used to describe the LISP-ALT AS 291 number the EID-prefix for the site is being carried for. The latter 292 is used to describe the AS that is carrying RLOC based prefixes in 293 the underlying routing system. 295 4.3. Convey Application Specific Data 297 When a locator-set needs to be conveyed based on the type of 298 application or the Per-Hop Behavior (PHB) of a packet, the 299 Application Data Type can be used. 301 Application Data LISP Canonical Address Format: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | AFI = 16387 | Rsvd1 | Flags | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 4 | Rsvd2 | 8 + n | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | IP TOS, IPv6 TC, or Flow Label | Protocol | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Local Port | Remote Port | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | AFI = x | Address ... | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Length value n: length in bytes of the AFI address that follows the 318 8-byte Application Data fields including the AFI field itself. 320 IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS 321 field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow 322 Label used in an IPv6 header. 324 Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP 325 transport header. 327 AFI = x: x can be any AFI value from [AFI]. 329 The Application Data Canonical Address Type is used for an EID 330 encoding when an ITR wants a locator-set for a specific application. 331 When used for an RLOC encoding, the ETR is supplying a locator-set 332 for each specific application is has been configured to advertise. 334 4.4. Assigning Geo Coordinates to Locator Addresses 336 If an ETR desires to send a Map-Reply describing the Geo Coordinates 337 for each locator in its locator-set, it can use the Geo Coordinate 338 Type to convey physical location information. 340 Geo Coordinate LISP Canonical Address Format: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | AFI = 16387 | Rsvd1 | Flags | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = 5 | Rsvd2 | 8 + n | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |N| Latitude Degrees | Minutes | Seconds | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |E| Longitude Degrees | Minutes | Seconds | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | AFI = x | Address ... | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Length value n: length in bytes of the AFI address that follows the 357 8-byte Longitude and Latitude fields including the AFI field 358 itself. 360 N: When set to 1 means North, otherwise South. 362 Latitude Degrees: Valid values range from 0 to 90. degrees above or 363 below the equator (northern or southern hemisphere, respectively). 365 Latitude Minutes: Valid values range from 0 to 59. 367 Latitude Seconds: Valid values range from 0 to 59. 369 E: When set to 1 means East, otherwise West. 371 Longitude Degrees: Value values are from 0 to 90 degrees right or 372 left of the Prime Meridian. 374 Longitude Minutes: Valid values range from 0 to 59. 376 Longitude Seconds: Valid values range from 0 to 59. 378 AFI = x: x can be any AFI value from [AFI]. 380 The Geo Coordinates Canonical Address Type can be used to encode 381 either EID or RLOC addresses. When used for EID encodings, you can 382 determine the physical location of an EID along with the topological 383 location by observing the locator-set. 385 4.5. Generic Database Mapping Lookups 387 When the LISP Mapping Database system holds information accessed by a 388 generic formatted key (where the key is not the usual IPv4 or IPv6 389 address), an opaque key may be desirable. 391 Opaque Key LISP Canonical Address Format: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | AFI = 16387 | Rsvd1 | Flags | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = 6 | Rsvd2 | n | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Key Field Num | Key Wildcard Fields | Key . . . | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | . . . Key | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Length value n: length in bytes of the type's payload. The value n 406 is the number of bytes that follow this Length field. 408 Key Field Num: the number of fields (minus 1) the key can be broken 409 up into. The width of the fields are fixed length. So for a key 410 size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 411 bytes in length. Valid values for this field range from 0 to 15 412 supporting a maximum of 16 field separations. 414 Key Wildcard Fields: describes which fields in the key are not used 415 as part of the key lookup. This wildcard encoding is a bitfield. 416 Each bit is a don't-care bit for a corresponding field in the key. 417 Bit 0 (the low-order bit) in this bitfield corresponds the first 418 field, right-justified in the key, bit 1 the second field, and so 419 on. When a bit is set in the bitfield it is a don't-care bit and 420 should not be considered as part of the database lookup. When the 421 entire 16-bits is set to 0, then all bits of the key are used for 422 the database lookup. 424 Key: the variable length key used to do a LISP Database Mapping 425 lookup. The length of the key is the value n (shown above) minus 426 3. 428 4.6. NAT Traversal Scenarios 430 When a LISP system is conveying global address and mapped port 431 information when traversing through a NAT device, the NAT-Traversal 432 LCAF Type is used. 434 NAT-Traversal Canonical Address Format: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | AFI = 16387 | Rsvd1 | Flags | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 7 | Rsvd2 | 4 + n | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Reserved | UDP Port Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | AFI = x | Global RLOC Address ... | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | AFI = x | Private RLOC Address ... | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | AFI = x | NTR RLOC Address 1 ... | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | AFI = x | NTR RLOC Address n ... | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Length value n: length in bytes of the AFI addresses that follows 455 the UDP Port Number field including the AFI fields themselves. 457 Reserved: must be set to zero and ignore on receipt. 459 UDP Port Number this is the port number returned to a LISP system 460 which was copied from the source port from a packet that has 461 flowed through a NAT device. 463 AFI = x: x can be any AFI value from [AFI]. 465 Global RLOC Address: this is an address known to be globally unique 466 built by NAT-traversal functionality in a LISP router. 468 Private RLOC Address: this is an address known to be a private 469 address inserted in this LCAF format by a LISP router that resides 470 on the private side of a NAT device. 472 NTR RLOC Address: this is an encapsulation address used by an ITR or 473 PITR which resides behind a NAT device. This address is known to 474 have state in a NAT device so packets can flow from it to the LISP 475 ETR behind the NAT. There can be one or more NTR addresses 476 supplied in these set of fields. The number of NTRs encoded is 477 determined by the LCAF length field. When there are no NTRs 478 supplied, the NTR fields can be omitted and reflected by the LCAF 479 length field or an AFI of 0 can be used to indicate zero NTRs 480 encoded. 482 4.7. PETR Admission Control Functionality 484 When a public PETR device wants to verify who is encapsulating to it, 485 it can check for a specific nonce value in the LISP encapsulated 486 packet. To convey the nonce to admitted ITRs or PITRs, this LCAF 487 format is used in a Map-Register or Map-Reply locator-record. 489 Nonce Locator Canonical Address Format: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | AFI = 16387 | Rsvd1 | Flags | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type = 8 | Rsvd2 | 4 + n | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Reserved | Nonce | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | AFI = x | Address ... | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Length value n: length in bytes of the AFI address that follows the 504 Nonce field including the AFI field itself. 506 Reserved: must be set to zero and ignore on receipt. 508 Nonce: this is a nonce value returned by an ETR in a Map-Reply 509 locator-record to be used by an ITR or PITR when encapsulating to 510 the locator address encoded in the AFI field of this LCAF type. 512 AFI = x: x can be any AFI value from [AFI]. 514 4.8. Multicast Group Membership Information 516 Multicast group information can be published in the mapping database 517 so a lookup on an EID based group address can return a replication 518 list of group addresses or a unicast addresses for single replication 519 or multiople head-end replications. This LCAF encoding can be used 520 to send broadcast packets to all members of a subnet when each EIDs 521 are away from their home subnet location. 523 Multicast Info Canonical Address Format: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | AFI = 16387 | Rsvd1 | Flags | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type = 9 | Rsvd2 | 4 + n | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Reserved | Source MaskLen| Group MaskLen | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | AFI = x | Source/Subnet Address ... | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | AFI = x | Group Address ... | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Length value n: length in bytes of fields that follow. 541 Reserved: must be set to zero and ignore on receipt. 543 Source MaskLen: the mask length of the source prefix that follows. 545 Group MaskLen: the mask length of the group prefix that follows. 547 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has 548 its own encoding of a multicast address, this field must be either 549 a group address or a broadcast address. 551 4.9. Traffic Engineering using Re-encapsulating Tunnels 553 For a given EID lookup into the mapping database, this LCAF format 554 can be returned to provide a list of locators in an explicit re- 555 encapsulation path. 557 Explicit Locator Path (ELP) Canonical Address Format: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | AFI = 16387 | Rsvd1 | Flags | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type = 10 | Rsvd2 | n | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | AFI = x | Reencap Hop 1 ... | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | AFI = x | Reencap Hop n ... | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Length value n: length in bytes of fields that follow. 573 AFI = x: x can be any AFI value from [AFI]. When a specific AFI has 574 its own encoding of a multicast address, this field must be either 575 a group address or a broadcast address. 577 4.10. Storing Security Data in the Mapping Database 579 When a locator in a locator-set has a security key associated with 580 it, this LCAF format will be used to encode key material. 582 Security Key Canonical Address Format: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | AFI = 16387 | Rsvd1 | Flags | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type = 11 | Rsvd2 | 4 + n | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Key-Wrap CID | Cipher ID | HMAC ID | Key Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Key Material ... | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | ... Key Material | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | AFI = x | Locator Address ... | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Length value n: length in bytes of fields that follow. 602 Key-Wrap CID: When the key is transmitted in this LCAF formatted as 603 ciphertext, then this Key Wrap Cipher ID indicates the cipher 604 algorithm used. The key used for this cipher is obtained out of 605 band. Values are assigned from [LISP-SEC]. 607 Cipher ID: Values are assigned from [LISP-SEC]. When the key is 608 used for a cipher for encryption or decryption, this field 609 indicates which cipher algorithm to use. 611 HMAC ID: Values are assigned from [LISP-SEC]. When the key is used 612 for a signature calculation, this field indicates what hash 613 algorithm to use. 615 Key Length: Length in bytes of key material that follows this field 616 and comes before the Locator address fields. 618 Key Material: Key material encoded as a public key when Cipher ID is 619 not a Null value. Key material encoded as a signature key when 620 HMAC ID is not a Null value. See [LISP-SEC] for value 621 assignments. 623 AFI = x: x can be any AFI value from [AFI].This is the locator 624 address that owns the encoded security key. 626 4.11. Applications for AFI List Type 628 4.11.1. Binding IPv4 and IPv6 Addresses 630 When header translation between IPv4 and IPv6 is desirable a LISP 631 Canonical Address can use the AFI List Type to carry multiple AFIs in 632 one LCA AFI. 634 Bounded Address LISP Canonical Address Format: 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | AFI = 16387 | Rsvd1 | Flags | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | AFI = 1 | IPv4 Address ... | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | ... IPv4 Address | AFI = 2 | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | IPv6 Address ... | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | ... IPv6 Address ... | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | ... IPv6 Address ... | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | ... IPv6 Address | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI 657 encoded addresses are used. 659 This type of address format can be included in a Map-Request when the 660 address is being used as an EID, but the Mapping Database System 661 lookup destination can use only the IPv4 address. This is so a 662 Mapping Database Service Transport System, such as LISP-ALT [ALT], 663 can use the Map-Request destination address to route the control 664 message to the desired LISP site. 666 4.11.2. Layer-2 VPNs 668 When MAC addresses are stored in the LISP Mapping Database System, 669 the AFI List Type can be used to carry AFI 6. 671 MAC Address LISP Canonical Address Format: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | AFI = 16387 | Rsvd1 | Flags | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Type = 1 | Rsvd2 | 2 + 6 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | AFI = 6 | Layer-2 MAC Address ... | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | ... Layer-2 MAC Address | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Length: length in bytes is fixed at 8 when MAC address AFI encoded 686 addresses are used. 688 This address format can be used to connect layer-2 domains together 689 using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. 690 In this use-case, a MAC address is being used as an EID, and the 691 locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or 692 even another MAC address being used as an RLOC. 694 4.11.3. ASCII Names in the Mapping Database 696 If DNS names or URIs are stored in the LISP Mapping Database System, 697 the AFI List Type can be used to carry an ASCII string where it is 698 delimited by length 'n' of the LCAF Length encoding. 700 ASCII LISP Canonical Address Format: 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | AFI = 16387 | Rsvd1 | Flags | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type = 1 | Rsvd2 | 2 + n | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | AFI = 17 | DNS Name or URI ... | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Length value n: length in bytes AFI=17 field and the null-terminated 713 ASCII string (the last byte of 0 is included). 715 4.11.4. Using Recursive LISP Canonical Address Encodings 717 When any combination of above is desirable, the AFI List Type value 718 can be used to carry within the LCA AFI another LCA AFI. 720 Recursive LISP Canonical Address Format: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | AFI = 16387 | Rsvd1 | Flags | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | AFI = 16387 | Rsvd1 | Flags | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type = 4 | Rsvd2 | 12 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | IP TOS, IPv6 QQS or Flow Label | Protocol | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Local Port | Remote Port | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | AFI = 1 | IPv4 Address ... | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | ... IPv4 Address | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is 743 included. 745 This format could be used by a Mapping Database Transport System, 746 such as LISP-ALT [ALT], where the AFI=1 IPv4 address is used as an 747 EID and placed in the Map-Request destination address by the sending 748 LISP system. The ALT system can deliver the Map-Request to the LISP 749 destination site independent of the Application Data Type AFI payload 750 values. When this AFI is processed by the destination LISP site, it 751 can return different locator-sets based on the type of application or 752 level of service that is being requested. 754 5. Security Considerations 756 There are no security considerations for this specification. The 757 security considerations are documented for the protocols that use 758 LISP Canonical Addressing. Refer to the those relevant 759 specifications. 761 6. IANA Considerations 763 The Address Family AFI definitions from [AFI] only allocate code- 764 points for the AFI value itself. The length of the address or entity 765 that follows is not defined and is implied based on conventional 766 experience. Where the LISP protocol uses LISP Canonical Addresses 767 specifically, the address length definitions will be in this 768 specification and take precedent over any other specification. 770 An IANA Registry for LCAF Type values will be created. The values 771 that are considered for use by the main LISP specification [LISP] 772 will be in the IANA Registry. Other Type values used for 773 experimentation will be defined and described in this document. 775 7. References 777 7.1. Normative References 779 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 780 October 1994. 782 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 783 E. Lear, "Address Allocation for Private Internets", 784 BCP 5, RFC 1918, February 1996. 786 7.2. Informative References 788 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 789 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 791 [ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 792 Alternative Topology (LISP+ALT)", 793 draft-ietf-lisp-alt-06.txt (work in progress), March 2011. 795 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 796 "Locator/ID Separation Protocol (LISP)", 797 draft-ietf-lisp-12.txt (work in progress), April 2011. 799 [LISP-SEC] 800 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 801 "LISP-Security (LISP-SEC", draft-ietf-lisp-sec-00.txt 802 (work in progress), July 2011. 804 Appendix A. Acknowledgments 806 The authors would like to thank Vince Fuller, Gregg Schudel, Jesper 807 Skriver, and Luigi Iannone for their technical and editorial 808 commentary. 810 The authors would like to thank Victor Moreno for discussions that 811 lead to the definition of the Multicast Info LCAF type. 813 The authors would like to thank Parantap Lahiri and Michael Kowal for 814 discussions that lead to the definition of the Explicit Locator Path 815 (ELP) LCAF type. 817 The authors would like to thank Fabio Maino and Vina Ermagan for 818 discussions that lead to the definition of the Security Key LCAF 819 type. 821 Thanks also goes to Terry Manderson for assistance obtaining a LISP 822 AFI value from IANA. 824 Authors' Addresses 826 Dino Farinacci 827 cisco Systems 828 Tasman Drive 829 San Jose, CA 95134 830 USA 832 Email: dino@cisco.com 834 Dave Meyer 835 cisco Systems 836 170 Tasman Drive 837 San Jose, CA 838 USA 840 Email: dmm@cisco.com 842 Job Snijders 843 InTouch N.V. 844 Middenweg 76 845 1097 BS Amsterdam 846 The Netherlands 848 Email: job@instituut.net