idnits 2.17.1 draft-farinacci-lisp-lcaf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 178: '...is reserved for future use and MUST be...' RFC 2119 keyword, line 201: '...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 -- The document date (October 12, 2010) is 4935 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-04 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft D. Meyer 4 Intended status: Experimental cisco Systems 5 Expires: April 15, 2011 J. Snijders 6 InTouch N.V. 7 October 12, 2010 9 LISP Canonical Address Format (LCAF) 10 draft-farinacci-lisp-lcaf-03 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 to IETF 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 15, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 60 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 61 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 62 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 63 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 64 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 65 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 66 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 11 67 4.6. Applications for AFI List Type . . . . . . . . . . . . . . 12 68 4.6.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 12 69 4.6.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . 14 70 4.6.3. ASCII Names in the Mapping Database . . . . . . . . . 14 71 4.6.4. Using Recursive LISP Canonical Address Encodings . . . 15 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The LISP architecture and protocols [LISP] introduces two new 83 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 84 (RLOCs) which are intended to replace most use of IP addresses on the 85 Internet. To provide flexibility for current and future 86 applications, these values can be encoded in LISP control messages 87 using a general syntax that includes Address Family Identifier (AFI), 88 length, and value fields. 90 Currently defined AFIs include IPv4 and IPv6 addresses, which are 91 formatted according to code-points assigned in [AFI] as follows: 93 IPv4 Encoded Address: 95 0 1 2 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | AFI = 1 | IPv4 Address ... | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | ... IPv4 Address | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 IPv6 Encoded Address: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | AFI = 2 | IPv6 Address ... | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | ... IPv6 Address ... | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | ... IPv6 Address ... | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | ... IPv6 Address ... | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | ... IPv6 Address | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 This document describes the currently-defined AFIs the LISP protocol 120 uses along with their encodings and introduces the LISP Canonical 121 Address Format (LCAF) that can be used to define the LISP-specific 122 encodings for arbitrary AFI values. 124 2. Definition of Terms 126 Address Family Identifier (AFI): a term used to describe an address 127 encoding in a packet. An address family currently defined for 128 IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The 129 reserved AFI value of 0 is used in this specification to indicate 130 an unspecified encoded address where the the length of the address 131 is 0 bytes following the 16-bit AFI value of 0. 133 Unspecified Address Format: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | AFI = 0 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 142 used in the source and destination address fields of the first 143 (most inner) LISP header of a packet. The host obtains a 144 destination EID the same way it obtains a destination address 145 today, for example through a DNS lookup or SIP exchange. The 146 source EID is obtained via existing mechanisms used to set a 147 host's "local" IP address. An EID is allocated to a host from an 148 EID-prefix block associated with the site where the host is 149 located. An EID can be used by a host to refer to other hosts. 151 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 152 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 153 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 154 numbered from topologically-aggregatable blocks that are assigned 155 to a site at each point to which it attaches to the global 156 Internet; where the topology is defined by the connectivity of 157 provider networks, RLOCs can be thought of as PA addresses. 158 Multiple RLOCs can be assigned to the same ETR device or to 159 multiple ETR devices at a site. 161 3. LISP Canonical Address Format Encodings 163 IANA has assigned AFI value 16387 (0x4003) to the LISP architecture 164 and protocols. This specification defines the encoding format of the 165 LISP Canonical Address (LCA). 167 The first 4 bytes of an LISP Canonical Address are followed by a 168 variable length of fields: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | AFI = 16387 | Rsvd1 | Flags | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Rsvd2 | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Rsvd1: this 8-bit field is reserved for future use and MUST be 179 transmitted as 0 and ignored on receipt. 181 Flags: this 8-bit field is for future definition and use. For now, 182 set to zero on transmission and ignored on receipt. 184 Type: this 8-bit field is specific to the LISP Canonical Address 185 formatted encodings, values are: 187 Type 0: Null Body Type 189 Type 1: AFI List Type 191 Type 2: Instance ID Type 193 Type 3: AS Number Type 195 Type 4: Application Data Type 197 Type 5: Geo Coordinates Type 199 Type 6: Opaque Key Type 201 Rsvd2: this 8-bit field is reserved for future use and MUST be 202 transmitted as 0 and ignored on receipt. 204 Length: this 16-bit field is in units of bytes and covers all of the 205 LISP Canonical Address payload, starting and including the byte 206 after the Length field. So any LCAF encoded address will have a 207 minimum length of 8 bytes when the Length field is 0. The 8 bytes 208 include the AFI, Flags, Type, Reserved, and Length fields. When 209 the AFI is not next to encoded address in a control message, then 210 the encoded address will have a minimum length of 2 bytes when the 211 Length field is 0. The 2 bytes include the Flags, Type, and 212 Length fields. 214 4. LISP Canonical Address Applications 216 4.1. Segmentation using LISP 218 When multiple organizations inside of a LISP site are using private 219 addresses [RFC1918] as EID-prefixes, their address spaces must remain 220 segregated due to possible address duplication. An Instance ID in 221 the address encoding can aid in making the entire AFI based address 222 unique. 224 Another use for the Instance ID LISP Canonical Address Format is when 225 creating multiple segmented VPNs inside of a LISP site where keeping 226 EID-prefix based subnets is desirable. 228 Instance ID LISP Canonical Address Format: 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | AFI = 16387 | Rsvd1 | Flags | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type = 2 | Rsvd2 | 4 + n | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Instance ID | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | AFI = x | Address ... | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Length value n: length in bytes of the AFI address that follows the 243 Instance ID field including the AFI field itself. 245 Instance ID: the low-order 24-bits that can go into a LISP data 246 header when the I-bit is set. See [LISP] for details. 248 AFI = x: x can be any AFI value from [AFI]. 250 This LISP Canonical Address Type can be used to encode either EID or 251 RLOC addresses. 253 4.2. Carrying AS Numbers in the Mapping Database 255 When an AS number is stored in the LISP Mapping Database System for 256 either policy or documentation reasons, it can be encoded in a LISP 257 Canonical Address. 259 AS Number LISP Canonical Address Format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | AFI = 16387 | Rsvd1 | Flags | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type = 3 | Rsvd2 | 4 + n | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | AS Number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AFI = x | Address ... | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Length value n: length in bytes of the AFI address that follows the 274 AS Number field including the AFI field itself. 276 AS Number: the 32-bit AS number of the autonomous system that has 277 been assigned either the EID or RLOC that follows. 279 AFI = x: x can be any AFI value from [AFI]. 281 The AS Number Canonical Address Type can be used to encode either EID 282 or RLOC addresses. The former is used to describe the LISP-ALT AS 283 number the EID-prefix for the site is being carried for. The latter 284 is used to describe the AS that is carrying RLOC based prefixes in 285 the underlying routing system. 287 4.3. Convey Application Specific Data 289 When a locator-set needs to be conveyed based on the type of 290 application or the Per-Hop Behavior (PHB) of a packet, the 291 Application Data Type can be used. 293 Application Data LISP Canonical Address Format: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | AFI = 16387 | Rsvd1 | Flags | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type = 4 | Rsvd2 | 8 + n | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | IP TOS, IPv6 TC, or Flow Label | Protocol | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Local Port | Remote Port | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | AFI = x | Address ... | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Length value n: length in bytes of the AFI address that follows the 310 8-byte Application Data fields including the AFI field itself. 312 IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS 313 field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow 314 Label used in an IPv6 header. 316 Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP 317 transport header. 319 AFI = x: x can be any AFI value from [AFI]. 321 The Application Data Canonical Address Type is used for an EID 322 encoding when an ITR wants a locator-set for a specific application. 323 When used for an RLOC encoding, the ETR is supplying a locator-set 324 for each specific application is has been configured to advertise. 326 4.4. Assigning Geo Coordinates to Locator Addresses 328 If an ETR desires to send a Map-Reply describing the Geo Coordinates 329 for each locator in its locator-set, it can use the Geo Coordinate 330 Type to convey physical location information. 332 Geo Coordinate LISP Canonical Address Format: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | AFI = 16387 | Rsvd1 | Flags | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type = 5 | Rsvd2 | 8 + n | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |N| Latitude Degrees | Minutes | Seconds | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |E| Longitude Degrees | Minutes | Seconds | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | AFI = x | Address ... | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Length value n: length in bytes of the AFI address that follows the 349 8-byte Longitude and Latitude fields including the AFI field 350 itself. 352 N: When set to 1 means North, otherwise South. 354 Latitude Degrees: Valid values range from 0 to 90. degrees above or 355 below the equator (northern or southern hemisphere, respectively). 357 Latitude Minutes: Valid values range from 0 to 59. 359 Latitude Seconds: Valid values range from 0 to 59. 361 E: When set to 1 means East, otherwise West. 363 Longitude Degrees: Value values are from 0 to 90 degrees right or 364 left of the Prime Meridian. 366 Longitude Minutes: Valid values range from 0 to 59. 368 Longitude Seconds: Valid values range from 0 to 59. 370 AFI = x: x can be any AFI value from [AFI]. 372 The Geo Coordinates Canonical Address Type can be used to encode 373 either EID or RLOC addresses. When used for EID encodings, you can 374 determine the physical location of an EID along with the topological 375 location by observing the locator-set. 377 4.5. Generic Database Mapping Lookups 379 When the LISP Mapping Database system holds information accessed by a 380 generally formated key (where the key is not the usual IPv4 or IPv6 381 address), an opaque key may be desirable. 383 Opaque Key LISP Canonical Address Format: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | AFI = 16387 | Rsvd1 | Flags | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type = 6 | Rsvd2 | n | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Key Field Num | Key Wildcard Fields | Key . . . | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | . . . Key | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Length value n: length in bytes of the type's payload. The value n 398 is the number of bytes that follow this Length field. 400 Key Field Num: the number of fields (minus 1) the key can be broken 401 up into. The width of the fields are fixed length. So for a key 402 size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 403 bytes in length. Valid values for this field range from 0 to 15 404 supporting a maximum of 16 field separations. 406 Key Wildcard Fields: describes which fields in the key are not used 407 as part of the key lookup. This wildcard encoding is a bitfield. 408 Each bit is a don't-care bit for a corresponding field in the key. 409 Bit 0 (the low-order bit) in this bitfield corresponds the first 410 field, right-justified in the key, bit 1 the second field, and so 411 on. When a bit is set in the bitfield it is a don't-care bit and 412 should not be considered as part of the database lookup. When the 413 entire 16-bits is set to 0, then all bits of the key are used for 414 the database lookup. 416 Key: the variable length key used to do a LISP Database Mapping 417 lookup. The length of the key is the value n (shown above) minus 418 3. 420 4.6. Applications for AFI List Type 422 4.6.1. Binding IPv4 and IPv6 Addresses 424 When header translation between IPv4 and IPv6 is desirable a LISP 425 Canonical Address can use the AFI List Type to carry multiple AFIs in 426 one LCA AFI. 428 Binded Address LISP Canonical Address Format: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | AFI = 16387 | Rsvd1 | Flags | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type = 2 | Rsvd2 | 2 + 4 + 2 + 16 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | AFI = 1 | IPv4 Address ... | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | ... IPv4 Address | AFI = 2 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | IPv6 Address ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | ... IPv6 Address ... | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | ... IPv6 Address ... | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | ... IPv6 Address | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI 451 encoded addresses are used. 453 This type of address format can be included in a Map-Request when the 454 address is being used as an EID, but the Mapping Database System 455 lookup destination can use only the IPv4 address. This is so a 456 Mapping Database Service Transport System, such as LISP-ALT [ALT], 457 can use the Map-Request destination address to route the control 458 message to the desired LISP site. 460 4.6.2. Layer-2 VPNs 462 When MAC addresses are stored in the LISP Mapping Database System, 463 the AFI List Type can be used to carry AFI 6. 465 MAC Address LISP Canonical Address Format: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | AFI = 16387 | Rsvd1 | Flags | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Type = 1 | Rsvd2 | 2 + 6 | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | AFI = 6 | Layer-2 MAC Address ... | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | ... Layer-2 MAC Address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Length: length in bytes is fixed at 8 when MAC address AFI encoded 480 addresses are used. 482 This address format can be used to connect layer-2 domains together 483 using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. 484 In this use-case, a MAC address is being used as an EID, and the 485 locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or 486 even another MAC address being used as an RLOC. 488 4.6.3. ASCII Names in the Mapping Database 490 If DNS names or URIs are stored in the LISP Mapping Database System, 491 the AFI List Type can be used to carry an ASCII string where it is 492 delimited by length 'n' of the LCAF Length encoding. 494 ASCII LISP Canonical Address Format: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | AFI = 16387 | Rsvd1 | Flags | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type = 1 | Rsvd2 | 2 + n | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | AFI = 17 | DNS Name or URI ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Length value n: length in bytes AFI=17 field and the null-terminated 507 ASCII string (the last byte of 0 is included). 509 4.6.4. Using Recursive LISP Canonical Address Encodings 511 When any combination of above is desirable, the AFI List Type value 512 can be used to carry within the LCA AFI another LCA AFI. 514 Recursive LISP Canonical Address Format: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | AFI = 16387 | Rsvd1 | Flags | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | AFI = 16387 | Rsvd1 | Flags | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type = 4 | Rsvd2 | 12 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | IP TOS, IPv6 QQS or Flow Label | Protocol | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Local Port | Remote Port | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | AFI = 1 | IPv4 Address ... | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | ... IPv4 Address | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is 537 included. 539 This format could be used by a Mapping Database Transport System, 540 such as LISP-ALT [ALT], where the AFI=1 IPv4 address is used as an 541 EID and placed in the Map-Request destination address by the sending 542 LISP system. The ALT system can deliver the Map-Request to the LISP 543 destination site independent of the Application Data Type AFI payload 544 values. When this AFI is processed by the destination LISP site, it 545 can return different locator-sets based on the type of application or 546 level of service that is being requested. 548 5. Security Considerations 550 There are no security considerations for this specification. The 551 security considerations are documented for the protocols that use 552 LISP Canonical Addressing. Refer to the those relevant 553 specifications. 555 6. IANA Considerations 557 The Address Family AFI definitions from [AFI] only allocate code- 558 points for the AFI value itself. The length of the address or entity 559 that follows is not defined and is implied based on conventional 560 experience. Where the LISP protocol uses LISP Canonical Addresses 561 specifically, the address length definitions will be in this 562 specification and take precedent over any other specification. 564 An IANA Registry for LCAF Type values will be created. The values 565 that are considered for use by the main LISP specification [LISP] 566 will be in the IANA Registry. Other Type values used for 567 experimentation will be defined and described in this document. 569 7. References 571 7.1. Normative References 573 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 574 October 1994. 576 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 577 E. Lear, "Address Allocation for Private Internets", 578 BCP 5, RFC 1918, February 1996. 580 7.2. Informative References 582 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 583 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 585 [ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 586 Alternative Topology (LISP+ALT)", 587 draft-ietf-lisp-alt-04.txt (work in progress), March 2010. 589 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 590 "Locator/ID Separation Protocol (LISP)", 591 draft-ietf-lisp-09.txt (work in progress), October 2010. 593 Appendix A. Acknowledgments 595 The authors would like to thank Vince Fuller, Gregg Schudel, Jesper 596 Skriver, and Luigi Iannone for their technical and editorial 597 commentary. 599 Thanks also goes to Terry Manderson for assistance obtaining a LISP 600 AFI value from IANA. 602 Authors' Addresses 604 Dino Farinacci 605 cisco Systems 606 Tasman Drive 607 San Jose, CA 95134 608 USA 610 Email: dino@cisco.com 612 Dave Meyer 613 cisco Systems 614 170 Tasman Drive 615 San Jose, CA 616 USA 618 Email: dmm@cisco.com 620 Job Snijders 621 InTouch N.V. 622 Middenweg 76 623 1097 BS Amsterdam 624 The Netherlands 626 Email: job@instituut.net