idnits 2.17.1 draft-farinacci-lisp-lcaf-00.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 147: '... EIDs MUST NOT be used as LISP RL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2010) is 5119 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-07 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: October 15, 2010 J. Snijders 6 InTouch 7 April 13, 2010 9 LISP Canonical Address Format (LCAF) 10 draft-farinacci-lisp-lcaf-00 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 15, 2010. 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 . . . . . . . . . . . . . 6 62 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 6 63 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 7 64 4.3. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . . . 8 65 4.4. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.5. ASCII Names in the Mapping Database . . . . . . . . . . . 9 67 4.6. Convey Application Specific Data . . . . . . . . . . . . . 10 68 4.7. Using Recursive LISP Canonical Address Encodings . . . . . 11 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 The LISP architecture and protocols [LISP] introduces two new 80 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 81 (RLOCs) which are intended to replace most use of IP addresses on the 82 Internet. To provide flexibility for current and future 83 applications, these values can be encoded in LISP control messages 84 using a general syntax that includes Address Family Identifier (AFI), 85 length, and value fields. 87 Currently defined AFIs include IPv4 and IPv6 addresses, which are 88 formatted according to code-points assigned in [AFI] as follows: 90 IPv4 Encoded Address: 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | AFI = 1 | IPv4 Address ... | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | ... IPv4 Address | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 IPv6 Encoded Address: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | AFI = 2 | IPv6 Address ... | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | ... IPv6 Address ... | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | ... IPv6 Address ... | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | ... IPv6 Address ... | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | ... IPv6 Address | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 This document describes the currently-defined AFIs along with their 117 encodings and introduces the LISP Canonical Address Format (LCAF) 118 that can be used to define the LISP-specific encodings for arbitrary 119 AFI values. 121 2. Definition of Terms 123 Address Family Identifier (AFI): a term used to describe an address 124 encoding in a packet. An address family currently defined for 125 IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The 126 reserved AFI value of 0 is used in this specification to indicate 127 an unspecified encoded address where the the length of the address 128 is 0 bytes following the 16-bit AFI value of 0. 130 Unspecified Address Format: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | AFI = 0 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 139 used in the source and destination address fields of the first 140 (most inner) LISP header of a packet. The host obtains a 141 destination EID the same way it obtains a destination address 142 today, for example through a DNS lookup or SIP exchange. The 143 source EID is obtained via existing mechanisms used to set a 144 host's "local" IP address. An EID is allocated to a host from an 145 EID-prefix block associated with the site where the host is 146 located. An EID can be used by a host to refer to other hosts. 147 EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be 148 assigned in a hierarchical manner, independent of the network 149 topology, to facilitate scaling of the mapping database. In 150 addition, an EID block assigned to a site may have site-local 151 structure (subnetting) for routing within the site; this structure 152 is not visible to the global routing system. When used in 153 discussions with other Locator/ID separation proposals, a LISP EID 154 will be called a "LEID". Throughout this document, any references 155 to "EID" refers to an LEID. 157 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 158 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 159 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 160 numbered from topologically-aggregatable blocks that are assigned 161 to a site at each point to which it attaches to the global 162 Internet; where the topology is defined by the connectivity of 163 provider networks, RLOCs can be thought of as PA addresses. 164 Multiple RLOCs can be assigned to the same ETR device or to 165 multiple ETR devices at a site. 167 3. LISP Canonical Address Format Encodings 169 IANA has assigned AFI value 16387 (0x4003) to the LISP architecture 170 and protocols. This specification defines the encoding format of the 171 LISP Canonical Address (LCA). 173 The first 4 bytes of an LISP Canonical Address are followed by a 174 variable length of fields: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | AFI = 16387 | Flags | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | . . . | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Flags: this 4-bit field is for future definition and use. For now, 185 set to zero on transmission and ignored on receipt. 187 Type: this 4-bit field is specific to the LISP Canonical Address 188 formatted encodings, values are: 190 Type 0: Null Body Type 192 Type 1: Instance ID Type 194 Type 2: AS Number Type 196 Type 3: AFI List Type 198 Type 4: Application Data Type 200 Length: this 8-bit field is in units of bytes and covers all of the 201 LISP Canonical Address payload, the AFI=16387, Flags, Type, and 202 Length fields. The Length field cannot be less than 4. When it 203 is set to 4, the Type must be 0 (the Null Body Type). The Null 204 Body Type can be used to convey LCA Flags. When the LCA Flags are 205 all set to 0, the encoding is similar to an unspecified address 206 encoding of an AFI=0 address. 208 4. LISP Canonical Address Applications 210 4.1. Segmentation using LISP 212 When multiple organizations inside of a LISP site are using private 213 addresses [RFC1918] as EID-prefixes, their address spaces must remain 214 segregated due to possible address duplication. An Instance ID in 215 the address encoding can aid in making the entire AFI based address 216 unique. 218 Another use for the Instance ID LISP Canonical Address Format is when 219 creating multiple segmented VPNs inside of a LISP site where keeping 220 EID-prefix based subnets is desirable. 222 Instance ID LISP Canonical Address Format: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | AFI = 16387 | Flags | 1 | 4 + 4 + n | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Instance ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | AFI = x | Address ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Length value n: length in bytes of the AFI address that follows 235 including the AFI field itself. 237 Instance ID: the low-order 24-bits that can go into a LISP data 238 header when the I-bit is set. See [LISP] for details. 240 AFI = x: x can be any AFI value from [AFI]. 242 This LISP Canonical Address Type can be used to encode either EID or 243 RLOC addresses. 245 4.2. Carrying AS Numbers in the Mapping Database 247 When an AS number is stored in the LISP Mapping Database System for 248 either policy or documentation reasons, it can be encoded in a LISP 249 Canonical Address. 251 AS Number LISP Canonical Address Format: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | AFI = 16387 | Flags | 2 | 4 + 4 + n | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | AS Number | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | AFI = x | Address ... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Length value n: length in bytes of the AFI address that follows 264 including the AFI field itself. 266 AS Number: the 32-bit AS number of the autonomous system that has 267 been assigned either the EID or RLOC that follows. 269 AFI = x: x can be any AFI value from [AFI]. 271 This LISP Canonical Address Type can be used to encode either EID or 272 RLOC addresses. The former is used to describe the LISP-ALT AS 273 number the EID-prefix for the site is being carried for. The latter 274 is used to describe the AS that is carrying RLOC based prefixes in 275 the underlying routing system. 277 4.3. Binding IPv4 and IPv6 Addresses 279 When header translation between IPv4 and IPv6 is desirable an LISP 280 Canonical Address can use the AFI List Type to carry multiple AFIs in 281 one LCA AFI. 283 Binded Address LISP Canonical Address Format: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | AFI = 16387 | Flags | 3 | 4+2+4+2+16 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | AFI = 1 | IPv4 Address ... | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | ... IPv4 Address | AFI = 2 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | IPv6 Address ... | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | ... IPv6 Address ... | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | ... IPv6 Address ... | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | ... IPv6 Address | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Length: length in bytes is fixed at 28 when IPv4 and IPv6 AFI 304 encoded addresses are used. 306 This type of address format can be included in a Map-Request when the 307 address is being used as an EID, but the Mapping Database System 308 lookup destination can use only the IPv4 address. This is so a 309 Mapping Database Service Transport System, such as LISP-ALT [ALT], 310 can use the Map-Request destination address to route the control 311 message to the desired LISP site. 313 4.4. Layer-2 VPNs 315 When MAC addresses are stored in the LISP Mapping Database System, 316 the AFI List Type can be used to carry AFI 6. 318 MAC Address LISP Canonical Address Format: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | AFI = 16387 | Flags | 3 | 4 + 2 + 6 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | AFI = 6 | Layer-2 MAC Address ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | ... Layer-2 MAC Address | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Length: length in bytes is fixed at 12 when MAC address AFI encoded 331 addresses are used. 333 This address format can be used to connect layer-2 domains together 334 using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. 335 In this use-case, a MAC address is being used as an EID, and the 336 locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or 337 even another MAC address being used as an RLOC. 339 4.5. ASCII Names in the Mapping Database 341 If DNS names or URIs are stored in the LISP Mapping Database System, 342 the AFI List Type can be used to carry an ASCII string where it is 343 delimited by length 'n' of the LCA Length encoding. 345 ASCII LISP Canonical Address Format: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | AFI = 16387 | Flags | 3 | 4 + 2 + n | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | AFI = 17 | DNS Name or URI ... | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Length value n: length in bytes AFI=17 field and the null-terminated 356 ASCII string (the last byte of 0 is included). 358 4.6. Convey Application Specific Data 360 When a locator-set needs to be conveyed based on the type of 361 application or the Per-Hop Behavior (PHB) of a packet, the 362 Application Data Type can be used. 364 Application Data LISP Canonical Address Format: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | AFI = 16387 | Flags | 4 | 4 + 8 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | IP TOS, IPv6 TC, or Flow Label | Protocol | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Local Port | Remote Port | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Length: length in bytes is fixed at 12. 378 IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS 379 field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow 380 Label used in an IPv6 header. 382 Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP 383 transport header. 385 4.7. Using Recursive LISP Canonical Address Encodings 387 When any combination of above is desirable, the AFI List Type value 388 can be used to carry within the LCA AFI another LCA AFI. 390 Recursive LISP Canonical Address Format: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | AFI = 16387 | Flags | 3 | 4+4+8+2+4 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | AFI = 16387 | Flags | 4 | 12 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | IP TOS, IPv6 QQS or Flow Label | Protocol | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Local Port | Remote Port | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | AFI = 1 | IPv4 Address ... | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | ... IPv4 Address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Length: length in bytes is fixed at 22 when an AFI=1 IPv4 address is 409 included. 411 This format could be used by a Mapping Database Transport System, 412 such as LISP-ALT [ALT], where the AFI=1 IPv4 address is used as an 413 EID and placed in the Map-Request destination address by the sending 414 LISP system. The ALT system can deliver the Map-Request to the LISP 415 destination site independent of the Application Data Type AFI payload 416 values. When this AFI is processed by the destination LISP site, it 417 can return different locator-sets based on the type of application or 418 level of service that is being requested. 420 5. Security Considerations 422 There are no security considerations for this specification. The 423 security considerations are documented for the protocols that use 424 LISP Canonical Addressing. Refer to the those relevant 425 specifications. 427 6. IANA Considerations 429 The Address Family AFI definitions from [AFI] only allocate code- 430 points for the AFI value itself. The length of the address or entity 431 that follows is not defined and is implied based conventional 432 experience. Where LISP uses LISP Canonical Addresses specifically, 433 the address length definitions will be in this specification and take 434 precedent over any other specification. 436 7. References 438 7.1. Normative References 440 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 441 October 1994. 443 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 444 E. Lear, "Address Allocation for Private Internets", 445 BCP 5, RFC 1918, February 1996. 447 7.2. Informative References 449 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 450 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 452 [ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 453 Alternative Topology (LISP+ALT)", 454 draft-ietf-lisp-alt-04.txt (work in progress), March 2010. 456 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 457 "Locator/ID Separation Protocol (LISP)", 458 draft-ietf-lisp-07.txt (work in progress), April 2010. 460 Appendix A. Acknowledgments 462 The authors would like to thank Vince Fuller, Gregg Schudel, and 463 Jesper Skriver for their technical and editorial commentary. 465 Thanks also goes to Terry Manderson for assistance obtaining a LISP 466 AFI value from IANA. 468 Authors' Addresses 470 Dino Farinacci 471 cisco Systems 472 Tasman Drive 473 San Jose, CA 95134 474 USA 476 Email: dino@cisco.com 478 Dave Meyer 479 cisco Systems 480 170 Tasman Drive 481 San Jose, CA 482 USA 484 Email: dmm@cisco.com 486 Job Snijders 487 InTouch 488 A Middenweg 76 489 Amsterdam, Netherlands 491 Email: job@instituut.net