idnits 2.17.1 draft-farinacci-lisp-lcaf-05.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 180: '...is reserved for future use and MUST be...' RFC 2119 keyword, line 207: '...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 455 has weird spacing: '... Number this ...' -- The document date (April 28, 2011) is 4747 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 Summary: 3 errors (**), 0 flaws (~~), 4 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: October 30, 2011 J. Snijders 6 InTouch N.V. 7 April 28, 2011 9 LISP Canonical Address Format (LCAF) 10 draft-farinacci-lisp-lcaf-05 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 October 30, 2011. 41 Copyright Notice 43 Copyright (c) 2011 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. NAT Travesal Scenarios . . . . . . . . . . . . . . . . . . 13 68 4.7. PETR Admission Control Functionality . . . . . . . . . . . 14 69 4.8. Applications for AFI List Type . . . . . . . . . . . . . . 15 70 4.8.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 15 71 4.8.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . 16 72 4.8.3. ASCII Names in the Mapping Database . . . . . . . . . 16 73 4.8.4. Using Recursive LISP Canonical Address Encodings . . . 17 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 The LISP architecture and protocols [LISP] introduces two new 85 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 86 (RLOCs) which are intended to replace most use of IP addresses on the 87 Internet. To provide flexibility for current and future 88 applications, these values can be encoded in LISP control messages 89 using a general syntax that includes Address Family Identifier (AFI), 90 length, and value fields. 92 Currently defined AFIs include IPv4 and IPv6 addresses, which are 93 formatted according to code-points assigned in [AFI] as follows: 95 IPv4 Encoded Address: 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | AFI = 1 | IPv4 Address ... | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | ... IPv4 Address | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 IPv6 Encoded Address: 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | AFI = 2 | IPv6 Address ... | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | ... IPv6 Address ... | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | ... IPv6 Address ... | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | ... IPv6 Address ... | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | ... IPv6 Address | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 This document describes the currently-defined AFIs the LISP protocol 122 uses along with their encodings and introduces the LISP Canonical 123 Address Format (LCAF) that can be used to define the LISP-specific 124 encodings for arbitrary AFI values. 126 2. Definition of Terms 128 Address Family Identifier (AFI): a term used to describe an address 129 encoding in a packet. An address family currently defined for 130 IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The 131 reserved AFI value of 0 is used in this specification to indicate 132 an unspecified encoded address where the the length of the address 133 is 0 bytes following the 16-bit AFI value of 0. 135 Unspecified Address Format: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | AFI = 0 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 144 used in the source and destination address fields of the first 145 (most inner) LISP header of a packet. The host obtains a 146 destination EID the same way it obtains a destination address 147 today, for example through a DNS lookup or SIP exchange. The 148 source EID is obtained via existing mechanisms used to set a 149 host's "local" IP address. An EID is allocated to a host from an 150 EID-prefix block associated with the site where the host is 151 located. An EID can be used by a host to refer to other hosts. 153 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 154 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 155 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 156 numbered from topologically-aggregatable blocks that are assigned 157 to a site at each point to which it attaches to the global 158 Internet; where the topology is defined by the connectivity of 159 provider networks, RLOCs can be thought of as PA addresses. 160 Multiple RLOCs can be assigned to the same ETR device or to 161 multiple ETR devices at a site. 163 3. LISP Canonical Address Format Encodings 165 IANA has assigned AFI value 16387 (0x4003) to the LISP architecture 166 and protocols. This specification defines the encoding format of the 167 LISP Canonical Address (LCA). 169 The first 4 bytes of an LISP Canonical Address are followed by a 170 variable length of fields: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | AFI = 16387 | Rsvd1 | Flags | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type | Rsvd2 | Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Rsvd1: this 8-bit field is reserved for future use and MUST be 181 transmitted as 0 and ignored on receipt. 183 Flags: this 8-bit field is for future definition and use. For now, 184 set to zero on transmission and ignored on receipt. 186 Type: this 8-bit field is specific to the LISP Canonical Address 187 formatted encodings, values are: 189 Type 0: Null Body Type 191 Type 1: AFI List Type 193 Type 2: Instance ID Type 195 Type 3: AS Number Type 197 Type 4: Application Data Type 199 Type 5: Geo Coordinates Type 201 Type 6: Opaque Key Type 203 Type 7: NAT-Traversal Type 205 Type 8: Nonce Locator Type 207 Rsvd2: this 8-bit field is reserved for future use and MUST be 208 transmitted as 0 and ignored on receipt. 210 Length: this 16-bit field is in units of bytes and covers all of the 211 LISP Canonical Address payload, starting and including the byte 212 after the Length field. So any LCAF encoded address will have a 213 minimum length of 8 bytes when the Length field is 0. The 8 bytes 214 include the AFI, Flags, Type, Reserved, and Length fields. When 215 the AFI is not next to encoded address in a control message, then 216 the encoded address will have a minimum length of 6 bytes when the 217 Length field is 0. The 6 bytes include the Flags, Type, Reserved, 218 and Length fields. 220 4. LISP Canonical Address Applications 222 4.1. Segmentation using LISP 224 When multiple organizations inside of a LISP site are using private 225 addresses [RFC1918] as EID-prefixes, their address spaces must remain 226 segregated due to possible address duplication. An Instance ID in 227 the address encoding can aid in making the entire AFI based address 228 unique. 230 Another use for the Instance ID LISP Canonical Address Format is when 231 creating multiple segmented VPNs inside of a LISP site where keeping 232 EID-prefix based subnets is desirable. 234 Instance ID LISP Canonical Address Format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | AFI = 16387 | Rsvd1 | Flags | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type = 2 | Rsvd2 | 4 + n | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Instance ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | AFI = x | Address ... | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Length value n: length in bytes of the AFI address that follows the 249 Instance ID field including the AFI field itself. 251 Instance ID: the low-order 24-bits that can go into a LISP data 252 header when the I-bit is set. See [LISP] for details. 254 AFI = x: x can be any AFI value from [AFI]. 256 This LISP Canonical Address Type can be used to encode either EID or 257 RLOC addresses. 259 4.2. Carrying AS Numbers in the Mapping Database 261 When an AS number is stored in the LISP Mapping Database System for 262 either policy or documentation reasons, it can be encoded in a LISP 263 Canonical Address. 265 AS Number LISP Canonical Address Format: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AFI = 16387 | Rsvd1 | Flags | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type = 3 | Rsvd2 | 4 + n | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AS Number | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | AFI = x | Address ... | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Length value n: length in bytes of the AFI address that follows the 280 AS Number field including the AFI field itself. 282 AS Number: the 32-bit AS number of the autonomous system that has 283 been assigned either the EID or RLOC that follows. 285 AFI = x: x can be any AFI value from [AFI]. 287 The AS Number Canonical Address Type can be used to encode either EID 288 or RLOC addresses. The former is used to describe the LISP-ALT AS 289 number the EID-prefix for the site is being carried for. The latter 290 is used to describe the AS that is carrying RLOC based prefixes in 291 the underlying routing system. 293 4.3. Convey Application Specific Data 295 When a locator-set needs to be conveyed based on the type of 296 application or the Per-Hop Behavior (PHB) of a packet, the 297 Application Data Type can be used. 299 Application Data LISP Canonical Address Format: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | AFI = 16387 | Rsvd1 | Flags | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type = 4 | Rsvd2 | 8 + n | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | IP TOS, IPv6 TC, or Flow Label | Protocol | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Local Port | Remote Port | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | AFI = x | Address ... | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Length value n: length in bytes of the AFI address that follows the 316 8-byte Application Data fields including the AFI field itself. 318 IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS 319 field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow 320 Label used in an IPv6 header. 322 Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP 323 transport header. 325 AFI = x: x can be any AFI value from [AFI]. 327 The Application Data Canonical Address Type is used for an EID 328 encoding when an ITR wants a locator-set for a specific application. 329 When used for an RLOC encoding, the ETR is supplying a locator-set 330 for each specific application is has been configured to advertise. 332 4.4. Assigning Geo Coordinates to Locator Addresses 334 If an ETR desires to send a Map-Reply describing the Geo Coordinates 335 for each locator in its locator-set, it can use the Geo Coordinate 336 Type to convey physical location information. 338 Geo Coordinate LISP Canonical Address Format: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | AFI = 16387 | Rsvd1 | Flags | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = 5 | Rsvd2 | 8 + n | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |N| Latitude Degrees | Minutes | Seconds | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |E| Longitude Degrees | Minutes | Seconds | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | AFI = x | Address ... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Length value n: length in bytes of the AFI address that follows the 355 8-byte Longitude and Latitude fields including the AFI field 356 itself. 358 N: When set to 1 means North, otherwise South. 360 Latitude Degrees: Valid values range from 0 to 90. degrees above or 361 below the equator (northern or southern hemisphere, respectively). 363 Latitude Minutes: Valid values range from 0 to 59. 365 Latitude Seconds: Valid values range from 0 to 59. 367 E: When set to 1 means East, otherwise West. 369 Longitude Degrees: Value values are from 0 to 90 degrees right or 370 left of the Prime Meridian. 372 Longitude Minutes: Valid values range from 0 to 59. 374 Longitude Seconds: Valid values range from 0 to 59. 376 AFI = x: x can be any AFI value from [AFI]. 378 The Geo Coordinates Canonical Address Type can be used to encode 379 either EID or RLOC addresses. When used for EID encodings, you can 380 determine the physical location of an EID along with the topological 381 location by observing the locator-set. 383 4.5. Generic Database Mapping Lookups 385 When the LISP Mapping Database system holds information accessed by a 386 generic formatted key (where the key is not the usual IPv4 or IPv6 387 address), an opaque key may be desirable. 389 Opaque Key LISP Canonical Address Format: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | AFI = 16387 | Rsvd1 | Flags | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type = 6 | Rsvd2 | n | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Key Field Num | Key Wildcard Fields | Key . . . | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | . . . Key | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Length value n: length in bytes of the type's payload. The value n 404 is the number of bytes that follow this Length field. 406 Key Field Num: the number of fields (minus 1) the key can be broken 407 up into. The width of the fields are fixed length. So for a key 408 size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 409 bytes in length. Valid values for this field range from 0 to 15 410 supporting a maximum of 16 field separations. 412 Key Wildcard Fields: describes which fields in the key are not used 413 as part of the key lookup. This wildcard encoding is a bitfield. 414 Each bit is a don't-care bit for a corresponding field in the key. 415 Bit 0 (the low-order bit) in this bitfield corresponds the first 416 field, right-justified in the key, bit 1 the second field, and so 417 on. When a bit is set in the bitfield it is a don't-care bit and 418 should not be considered as part of the database lookup. When the 419 entire 16-bits is set to 0, then all bits of the key are used for 420 the database lookup. 422 Key: the variable length key used to do a LISP Database Mapping 423 lookup. The length of the key is the value n (shown above) minus 424 3. 426 4.6. NAT Travesal Scenarios 428 When a LISP system is conveying global address and mapped port 429 information when traversing through a NAT device, the NAT-Traversal 430 LCAF Type is used. 432 NAT-Traversal Canonical Address Format: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | AFI = 16387 | Rsvd1 | Flags | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type = 7 | Rsvd2 | 4 + n | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Reserved | UDP Port Number | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | AFI = x | Global RLOC Address ... | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | AFI = x | Private RLOC Address ... | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | AFI = x | NTR RLOC Address ... | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Length value n: length in bytes of the AFI addresses that follows 451 the UDP Port Number field including the AFI fields themselves. 453 Reserved: must be set to zero and ignore on receipt. 455 UDP Port Number this is the port number returned to a LISP system 456 which was copied from the source port from a packet that has 457 flowed through a NAT device. 459 AFI = x: x can be any AFI value from [AFI]. 461 Global RLOC Address: this is an address known to be globally unique 462 built by NAT-traversal functionality in a LISP router. 464 Private RLOC Address: this is an address known to be a private 465 address inserted in this LCAF format by a LISP router that resides 466 on the private side of a NAT device. 468 NTR RLOC Address: this is an encapsulation address used by an ITR or 469 PITR which resides behind a NAT device. This address is known to 470 have state in a NAT device so packets can flow from it to the LISP 471 ETR behind the NAT. 473 4.7. PETR Admission Control Functionality 475 When a public PETR device wants to verify who is encapsulating to it, 476 it can check for a specific nonce value in the LISP encapsulated 477 packet. To convey the nonce to admitted ITRs or PITRs, this LCAF 478 format is used in a Map-Register or Map-Reply locator-record. 480 Nonce Locator Canonical Address Format: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | AFI = 16387 | Rsvd1 | Flags | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type = 8 | Rsvd2 | 4 + n | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Reserved | Nonce | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | AFI = x | Address ... | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Length value n: length in bytes of the AFI address that follows the 495 Nonce field including the AFI field itself. 497 Reserved: must be set to zero and ignore on receipt. 499 Nonce: this is a nonce value returned by an ETR in a Map-Reply 500 locator-record to be used by an ITR or PITR when encapsulating to 501 the locator address encoded in the AFI field of this LCAF type. 503 AFI = x: x can be any AFI value from [AFI]. 505 4.8. Applications for AFI List Type 507 4.8.1. Binding IPv4 and IPv6 Addresses 509 When header translation between IPv4 and IPv6 is desirable a LISP 510 Canonical Address can use the AFI List Type to carry multiple AFIs in 511 one LCA AFI. 513 Bounded Address LISP Canonical Address Format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | AFI = 16387 | Rsvd1 | Flags | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | AFI = 1 | IPv4 Address ... | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | ... IPv4 Address | AFI = 2 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | IPv6 Address ... | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | ... IPv6 Address ... | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | ... IPv6 Address ... | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | ... IPv6 Address | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI 536 encoded addresses are used. 538 This type of address format can be included in a Map-Request when the 539 address is being used as an EID, but the Mapping Database System 540 lookup destination can use only the IPv4 address. This is so a 541 Mapping Database Service Transport System, such as LISP-ALT [ALT], 542 can use the Map-Request destination address to route the control 543 message to the desired LISP site. 545 4.8.2. Layer-2 VPNs 547 When MAC addresses are stored in the LISP Mapping Database System, 548 the AFI List Type can be used to carry AFI 6. 550 MAC Address LISP Canonical Address Format: 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | AFI = 16387 | Rsvd1 | Flags | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type = 1 | Rsvd2 | 2 + 6 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | AFI = 6 | Layer-2 MAC Address ... | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ... Layer-2 MAC Address | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Length: length in bytes is fixed at 8 when MAC address AFI encoded 565 addresses are used. 567 This address format can be used to connect layer-2 domains together 568 using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. 569 In this use-case, a MAC address is being used as an EID, and the 570 locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or 571 even another MAC address being used as an RLOC. 573 4.8.3. ASCII Names in the Mapping Database 575 If DNS names or URIs are stored in the LISP Mapping Database System, 576 the AFI List Type can be used to carry an ASCII string where it is 577 delimited by length 'n' of the LCAF Length encoding. 579 ASCII LISP Canonical Address Format: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | AFI = 16387 | Rsvd1 | Flags | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type = 1 | Rsvd2 | 2 + n | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | AFI = 17 | DNS Name or URI ... | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Length value n: length in bytes AFI=17 field and the null-terminated 592 ASCII string (the last byte of 0 is included). 594 4.8.4. Using Recursive LISP Canonical Address Encodings 596 When any combination of above is desirable, the AFI List Type value 597 can be used to carry within the LCA AFI another LCA AFI. 599 Recursive LISP Canonical Address Format: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | AFI = 16387 | Rsvd1 | Flags | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | AFI = 16387 | Rsvd1 | Flags | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type = 4 | Rsvd2 | 12 | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | IP TOS, IPv6 QQS or Flow Label | Protocol | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Local Port | Remote Port | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | AFI = 1 | IPv4 Address ... | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | ... IPv4 Address | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is 622 included. 624 This format could be used by a Mapping Database Transport System, 625 such as LISP-ALT [ALT], where the AFI=1 IPv4 address is used as an 626 EID and placed in the Map-Request destination address by the sending 627 LISP system. The ALT system can deliver the Map-Request to the LISP 628 destination site independent of the Application Data Type AFI payload 629 values. When this AFI is processed by the destination LISP site, it 630 can return different locator-sets based on the type of application or 631 level of service that is being requested. 633 5. Security Considerations 635 There are no security considerations for this specification. The 636 security considerations are documented for the protocols that use 637 LISP Canonical Addressing. Refer to the those relevant 638 specifications. 640 6. IANA Considerations 642 The Address Family AFI definitions from [AFI] only allocate code- 643 points for the AFI value itself. The length of the address or entity 644 that follows is not defined and is implied based on conventional 645 experience. Where the LISP protocol uses LISP Canonical Addresses 646 specifically, the address length definitions will be in this 647 specification and take precedent over any other specification. 649 An IANA Registry for LCAF Type values will be created. The values 650 that are considered for use by the main LISP specification [LISP] 651 will be in the IANA Registry. Other Type values used for 652 experimentation will be defined and described in this document. 654 7. References 656 7.1. Normative References 658 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 659 October 1994. 661 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 662 E. Lear, "Address Allocation for Private Internets", 663 BCP 5, RFC 1918, February 1996. 665 7.2. Informative References 667 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 668 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 670 [ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 671 Alternative Topology (LISP+ALT)", 672 draft-ietf-lisp-alt-06.txt (work in progress), March 2011. 674 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 675 "Locator/ID Separation Protocol (LISP)", 676 draft-ietf-lisp-12.txt (work in progress), April 2011. 678 Appendix A. Acknowledgments 680 The authors would like to thank Vince Fuller, Gregg Schudel, Jesper 681 Skriver, and Luigi Iannone for their technical and editorial 682 commentary. 684 Thanks also goes to Terry Manderson for assistance obtaining a LISP 685 AFI value from IANA. 687 Authors' Addresses 689 Dino Farinacci 690 cisco Systems 691 Tasman Drive 692 San Jose, CA 95134 693 USA 695 Email: dino@cisco.com 697 Dave Meyer 698 cisco Systems 699 170 Tasman Drive 700 San Jose, CA 701 USA 703 Email: dmm@cisco.com 705 Job Snijders 706 InTouch N.V. 707 Middenweg 76 708 1097 BS Amsterdam 709 The Netherlands 711 Email: job@instituut.net