idnits 2.17.1 draft-herbert-ila-ilamp-00.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 316: '... Hello message MUST be sent by each ...' RFC 2119 keyword, line 600: '.... The connection MUST be terminated an...' RFC 2119 keyword, line 604: '...is an error and the connection MUST be...' RFC 2119 keyword, line 605: '...nd error message SHOULD be logged. Bot...' RFC 2119 keyword, line 644: '... MUST be ILA translated and forwarde...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2017) is 2318 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ILABGP' is mentioned on line 121, but not defined == Missing Reference: 'RFC5246' is mentioned on line 831, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC8200' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'BGPILA' is defined on line 865, but no explicit reference was found in the text ** Downref: Normative reference to an Draft Standard RFC: RFC 4291 == Outdated reference: A later version (-01) exists of draft-herbert-intarea-ila-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: June 2018 6 December 21, 2017 8 Identifier Locator Addressing Mapping Protocol 9 draft-herbert-ila-ilamp-00 11 Abstract 13 Identifier-locator protocols rely on a mapping system that is able to 14 map identifiers to locators. ILA nodes that perform ILA translations 15 need to access the mapping system via a protocol. This document 16 specifies the ILA Mapping Protocol that is used by ILA forwarding 17 nodes and hosts to populate and maintain a cache of ILA mappings. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2 Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Functional components . . . . . . . . . . . . . . . . . . . 5 60 2.2 ILA forwarding nodes and hosts . . . . . . . . . . . . . . . 5 61 2.2.1 ILA forwarding nodes . . . . . . . . . . . . . . . . . . 5 62 2.2.2 ILA hosts . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3 ILA address to SIR address translation . . . . . . . . . 5 64 2.2.4 ILA Forwarding . . . . . . . . . . . . . . . . . . . . . 5 65 2.3 ILA routers . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.3.1 Forwarding routers . . . . . . . . . . . . . . . . . . . 6 67 2.3.2 Mapping routers . . . . . . . . . . . . . . . . . . . . 6 68 2.3.3 ILA router synchronization . . . . . . . . . . . . . . . 7 69 3 ILA Mapping Protocol . . . . . . . . . . . . . . . . . . . . . 7 70 3.1 Common header format . . . . . . . . . . . . . . . . . . . . 8 71 3.2 Hello messages . . . . . . . . . . . . . . . . . . . . . . . 8 72 4 ILAMP Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1 Map request . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2 Map information . . . . . . . . . . . . . . . . . . . . . . 10 75 4.3 Extended map information . . . . . . . . . . . . . . . . . . 11 76 4.4 Locator unreachable . . . . . . . . . . . . . . . . . . . . 12 77 4.5 Identifier and locator types . . . . . . . . . . . . . . . . 13 78 4.5.1 Identifier types . . . . . . . . . . . . . . . . . . . . 13 79 4.5.2 Locator types . . . . . . . . . . . . . . . . . . . . . 13 80 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1 Version negotiation . . . . . . . . . . . . . . . . . . . . 14 82 5.2 Populating an ILA cache . . . . . . . . . . . . . . . . . . 14 83 5.2.1 ILA Redirects . . . . . . . . . . . . . . . . . . . . . 15 84 5.2.1.1 Proactive push with redirect . . . . . . . . . . . . 15 85 5.2.1.2 Redirect rate limiting . . . . . . . . . . . . . . . 15 86 5.2.2 Map request/reply . . . . . . . . . . . . . . . . . . . 15 87 5.2.3 Push mappings . . . . . . . . . . . . . . . . . . . . . 16 88 5.3 Cache maintenance . . . . . . . . . . . . . . . . . . . . . 16 89 5.3.1 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.3.2 Cache refresh . . . . . . . . . . . . . . . . . . . . . 16 91 5.3.3 Cache timeout values . . . . . . . . . . . . . . . . . . 17 92 5.4 ILA forwarding node and host receive processing . . . . . . 17 93 5.5 Locator unreachable handling . . . . . . . . . . . . . . . . 17 94 5.6 Control Connections . . . . . . . . . . . . . . . . . . . . 18 95 5.7 Protocol errors . . . . . . . . . . . . . . . . . . . . . . 18 96 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 97 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 98 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 100 8.2 Informative References . . . . . . . . . . . . . . . . . . 20 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 1 Introduction 105 The ILA Mapping Protocol (ILAMP) is a control plane protocol that 106 provides ILA nodes mapping information. ILA [ILA] nodes that perform 107 ILA translation rely on a mapping system to provide identifier to 108 locator mappings. There are two levels of mapping protocols to be 109 defined: one used by ILA routers that require the full set of ILA 110 mappings for a domain, and one used by ILA nodes that maintain a 111 caches of mappings. 113 The ILA mapping system is effectively a key/value database that maps 114 identifiers to locators. The protocol for sharing mapping information 115 amongst ILA routers, nodes that maintain a full table of mappings, 116 can thus be a database. A database schema for the ILA mapping system 117 will be described in a separate document. 119 ILA separates the control plane from the data plane, so alternative 120 control plane protocols may be used with a common data plane. For 121 instance, BGP could be used as a mapping system protocol [ILABGP]. 123 2 Reference topology 125 This section provides a reference topology forILA. 127 The topology is general however can be adapted to specific ILA use 128 cases such as data center virtualization and mobility networks. 130 Internet 131 | 132 +-----------------+ 133 | ILA-FR | 134 |Forwarding router| 135 +--------+--------+ 136 +------------+ _____|_____ +------------+ 137 | ILA-MR | ( Shared ) | ILA-MR | 138 | IMP router +-------( Database )-------+ IMP router | 139 +------+-----+ (___________) +------+-----+ 140 | | 141 +-------+--+----------+ +----------+--+-------+ 142 | | | | | | 143 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +-------+ 144 | ILA-N | | ILA-N | | ILA-H | | ILA-N | | ILA-N | | ILA-H | 145 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 146 | | | | 147 End hosts End hosts End hosts End hosts 149 2.1 Functional components 151 There are four types of functional nodes in the ILA architecture: 153 ILA-N: ILA forwarding nodes 155 ILA-H: ILA hosts 157 ILA-FR: ILA forwarding routers 159 ILA-MR: ILA mapping routers 161 2.2 ILA forwarding nodes and hosts 163 2.2.1 ILA forwarding nodes 165 ILA forwarding nodes (ILA-N) are deployed in the network 166 infrastructure towards the edges to provide caches for ILA 167 forwarding. ILA forwarding nodes have two functions: ILA address to 168 SIR address translation and ILA forwarding. As indicated in the 169 reference topology, forwarding nodes may deployed near the point of 170 device attachment (e.g. base station, eNodeB) of user devices (e.g. 171 UEs). 173 2.2.2 ILA hosts 175 ILA hosts (ILA-H) are end hosts that participate in ILA. These may be 176 servers that provide ILA to work with virtualization techniques such 177 as VMs or containers. ILA hosts perform the same functions as ILA 178 forwarding nodes, however the source of packets is local to the same 179 host so there are some optimizations that may be applied. 181 2.2.3 ILA address to SIR address translation 183 ILA forwarding nodes and hosts perform ILA address to SIR address 184 translation. This is a reverse ILA translation in order to restore 185 the original addresses in a packet for delivery. Forwarding the 186 packet on to the destination is done based on the SIR address. For 187 instance, a forwarding node may map a SIR address to a layer 2 188 address of a directly attached device that has the SIR address. Note 189 that this functionality is required somewhere in the path between the 190 node that writes a locator into an address and the ultimate 191 destination device. 193 2.2.4 ILA Forwarding 195 An ILA forwarding node or host may perform ILA translation and 196 forward packets directly to peer ILA nodes in the same domain. The 197 mappings for this are maintained in a working set cache. As a cache 198 there must be methods to populate, evict, and timeout entries. A 199 cache is considered an optimization so the system should be 200 functional without its use (e.g. if the cache has no entries). 202 2.3 ILA routers 204 ILA routers (denoted by ILA-R*) are deployed within the network 205 infrastructure and collectively contain a database of all identifier 206 to locator mappings in the domain, as well as all identifier group 207 information for the domain. The database may be sharded across some 208 number of ILA routers for scalability. ILA routers that maintain the 209 database or a shard may be replicated for scalability and 210 availability. 212 ILA routers provide two main functions: ILA forwarding and mapping 213 resolution. An ILA router may perform one or the other of these 214 functions or may provide both at the same time. 216 2.3.1 Forwarding routers 218 Forwarding routers (ILA-FR) perform ILA translation when packets 219 enter a domain. A destination address of a packet that is a SIR 220 address is translated to an ILA address. The process is that the 221 router performs a lookup on the destination address in the mapping 222 table and a locator is returned. The locator is written into the 223 destination address of the packet (that is the high order sixty-four 224 bits are overwritten with a locator). 226 In the case of a sharded database being used, the high order bits of 227 the identifier indicate the shard number. This is included in a 228 routing prefix so that the packet is routed to an ILA router that 229 contains the database for the relevant shard. 231 2.3.2 Mapping routers 233 A mapping router (ILA-MR) provides ILA forwarding nodes and hosts 234 mapping information. A mapping router may also perform ILA 235 translations and forwarding. A mapping router implements ILAMP to 236 communicate with ILA forwarding nodes and hosts. Mapping information 237 is provided by a request/reply protocol, ILA redirects, or by a push 238 mechanism. 240 An ILA router that is performing mapping resolution will respond to 241 mapping requests from ILA forwarding nodes or ILA hosts. The mapping 242 request protocol allows a node to request the locator information for 243 an identifier address. 245 A mapping router can send ILA redirects to ILA forwarding nodes and 246 ILA hosts in order to inform them of a direct ILA path. A redirect is 247 sent to the upstream ILA forwarding node or host of the source which 248 is determined by an ILA lookup the source address. 250 2.3.3 ILA router synchronization 252 ILA routers, both those that are forwarding and those that provide 253 mapping resolution, must synchronize the contents of the database. 254 This synchronization is done for each shard. When a change occurs to 255 an identifier-locator mapping, for instance the locator for an 256 identifier changes, the shard that contains the identifier must be 257 synchronized in as little time to converge as possible. 259 There are a number of options to use for implementing the ILA mapping 260 system and router protocol. One option is to use a key/value database 261 (such as a NoSQL database like Redis). 263 The idea of the database is that each shard is a distributed database 264 instance with some number of replicas. When a write is done in the 265 database, the change is propagated throughout all of the replicas for 266 the shard using the standard database replication mechanisms. Mapping 267 information is written to the database using common database API and 268 requires authenticated write permissions. Each ILA router can read 269 the database for the associated shard to perform its function. 271 The specifics of applying a database and a database schema for ILA 272 will be provided in other documents. 274 3 ILA Mapping Protocol 276 The ILA Mapping Protocol (ILAMP) is used between ILA forwarding nodes 277 and ILA mapping routers. The purpose of the protocol is to populate 278 and maintain the ILA mapping cache in forwarding nodes. 280 ILAMP defines redirects, a request/response protocol, and a push 281 mechanism to populate the mapping table. Unlike traditional routing 282 protocols that run over UDP, this protocol is intended to be run over 283 TCP. TCP provides reliability, statefulness implied by established 284 connections, ordering, and security in the form of TLS. Secure 285 redirects are facilitated by the use of TCP. 287 ILAMP is used to send message between ILA routers and ILA forwarding 288 nodes or hosts. The messages are sent over the TCP stream and must be 289 delineated by a receiver. Different versions of ILAMP are allowed and 290 the version used for communication is negotiated by Hello messages. 292 3.1 Common header format 294 All ILAMP messages begin with a two octet common header: 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 The contents of the common header are: 302 o Type: Indicates the type of message. A type 0 message is a hello 303 message. Types greater than zero are interpreted per the 304 negotiated version. 306 o Length: Length of the message in octets. This includes the common 307 header. The minimal length of a message is 2 octets and the 308 maximum length is 1,048,575 octets. 310 Following the two octet common header is variable length data that is 311 specific to the version and type the message. 313 3.2 Hello messages 315 Hello messages indicate the versions of ILAMP that a node supports. 316 Hello message MUST be sent by each side as the first message in the 317 connection. 319 The format of an ILAMP Hello message is: 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | 0 | 4 |R| Rsvd | MinV | MaxV | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The contents of the Hello message are: 327 o Type = 0. This is indicates the type is a Hello message. 329 o Router bit: Indicates the sender is an ILA router. If the sender 330 is an ILA forwarding node or host this bit is cleared. 332 o Rsvd: Reserved bits. Must be set to zero on transmit. 334 o MinV: Minimum version number supported by the sending node. 336 o MaxV: Maximum version number supported by the sending node. 338 Version numbers are from 0 to 15. This document describes version 0 339 of ILAMP. 341 4 ILAMP Version 0 343 The message types in version 0 of IMP are: 345 o Map request (Type = 1) 347 o Map information (Type = 2) 349 o Extended map information (Type = 3) 351 o Locator unreachable (Type = 4) 353 4.1 Map request 355 A map request is sent by an ILA forwarding node or host to an ILA 356 mapping router to request mapping information for a list of 357 identifiers. The format of a map request is: 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 0 | Length | Rsvd | IDType| 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 362 | | | 363 ~ Identifier ~ ent 364 | | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 367 The contents of the map request message are: 369 o Type = 1. This is indicates the type is map request. 371 o Length: Set to 4 plus the size of the identifier times the number 372 of identifiers in the list. 374 o Rsvd: Reserved bits. Must be set to zero when sending. 376 o IDType: Identifier type. Specifies the identifier type. This also 377 implies the length of each identifier in the request list. 378 Identifier types are defined below. 380 o Identifier: An identifier of type indicated by IDType. The size 381 of an identifier is specified by the type. 383 The Identifier field is repeated for each identifier in the list. The 384 number of identifiers being requested is (message length - 4) / 385 (identifier size). 387 4.2 Map information 389 Map information messages are sent by an ILA router to an ILA 390 forwarding node or host. This message provides a list of identifier 391 to locator mappings. The format of a map information message is: 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | 2 | Length | Rsvd |SubType|LocType| IDType| 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 396 | | | 397 ~ Identifier ~ e 398 | | n 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 400 | | | 401 ~ Locator ~ | 402 | |/ 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 The contents of the map information message are: 407 o Type = 2. This is indicates the type is map information. 409 o Length: Set to 4 plus the size of an identifier and locator times 410 the number of identifier/locator pairs in the list. 412 o Rsvd: Reserved bits. Must be set to zero when sending. 414 o SubType: Specifies the reason that ILA-R sent this message. Sub 415 types are 417 o 0: Redirect 419 o 1: Map reply to a map request 421 o 2: Push map information 423 o LocType: Locator type. Specifies the locator type. This also 424 implies the length of each locator in the list. Locator types are 425 defined below. 427 o IDType: Identifier type. Specifies the identifier type. This also 428 implies the length of each identifier in the list. Identifier 429 types are defined below. 431 o Identifier: An identifier of type indicated by IDType. The size 432 of an identifier is specified by the type. 434 o Locator: A locator of type indicated by LocType. The size of a 435 locator is specified by the type. 437 The Identifier/Locator pair is repeated for each mapping being 438 reported in the list. The number of identifiers being requested is 439 (message length - 4) / (identifier size + locator size). 441 4.3 Extended map information 443 An extended locator map information message is sent by an ILA router 444 to associate more than one locator with an identifier as well as 445 providing an expiration time for an identifier locator mapping and 446 additional locator specific attributes. The format of an extended map 447 information is: 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | 3 | Length | Rsvd |SubType|LocType|IDType | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ 452 | | | 453 ~ Identifier ~ | 454 | | r 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 456 | Num locator | Record timeout | c 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ o 458 | Prio | Rsvd | Weight | Rsvd | e r 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t d 460 | | t | 461 ~ Locator ~ | | 462 | |/ | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ 465 The contents of the map reply message are: 467 o Type = 3. This indicates an extended map information message 469 o Length: Set to 4 plus the sum of sizes for each identifier record 470 in the list. 472 o Rsvd: Reserved bits. Must be set to zero when sending. 474 o SubType: Specifies the reason that an ILA router sent this 475 messages. Sub types are: 477 o 0: Map reply to a map request 479 o 1: Redirect 481 o 2: Push map information 483 o LocType: Locator type. Specifies the locator type. This also 484 implies the length of each locator in the list. Locator types are 485 defined below. 487 o IDType: Identifier type. Specifies the identifier type. This also 488 implies the length of each identifier in the list. Identifier 489 types are defined below. 491 o Num locator: Number of locators being reported for an identifier. 493 o Record timeout: The time to live for the identifier information 494 in seconds. A value of zero indicates the default is used. 496 o Priority: Relative priority of a locator. Locators with higher 497 priority values have preference to be used. Locators that have 498 the same priority may be used for load balancing. 500 o Weight: Relative weights assigned to each locator. In the case 501 that locators have the same priority the weights are used to 502 control how traffic is distributed. A weight of zero indicates no 503 weight and the mapping is not used unless all locators for the 504 same priority have a weight of zero. 506 o Locator: A locator of type specified in LocType. 508 The identifier record is repeated for each mapping being reported and 509 the locator entry is repeated for each locator being reported for an 510 identifier. The total number of identifiers being reported is 511 determined by parsing the message. 513 4.4 Locator unreachable 515 A locator unreachable message is sent by an ILA router to ILA 516 forwarding node or host in the event that a locator or locators are 517 known to no longer be reachable. The format of a locator unreachable 518 message is: 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | 4 | Length | Rsvd |LocType| Rsvd | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 523 | | | 524 ~ Locator ~ ent 525 | | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 528 The contents of the locator ureachable message are: 530 o Type = 4. This is indicates the type is a locator unreachable 531 message. 533 o Length: Set to 4 plus the size of the locator times the number of 534 locators in the list. 536 o Rsvd: Reserved bits. Must be set to zero when sending. 538 o LocType: Locator type. Specifies the locator type. This also 539 implies the length of each locator in the list. Locator types are 540 defined below. 542 o Locator: A locator of type indicated by LocType. The size of a 543 locator is specified by the type. 545 The Locator field is repeated for each locator in the list. The 546 number of locators being reported is (message length - 4) / (locator 547 size). 549 4.5 Identifier and locator types 551 4.5.1 Identifier types 553 Identifier types used in IDType fields of ILAMP messages are: 555 o IPv6 address (IDType = 1): 128 bit IPv6 address 557 o ILA Identifier (IDType = 2): 64 bit ILA identifier 559 o 32 bit index (IDType = 3): 32 bit index into an identifier table 561 o 64 bit index (IDType = 4): 64 bit index into an identifier table 563 For the table index types it is assumed that a table mapping index to 564 and identifier is shared with ILA forwarding nodes and hosts. 566 4.5.2 Locator types 568 Locator types used in LocType fields of ILAMP messages are: 570 o IPv6 address (LocType = 1): 128 bit IPv6 address 572 o ILA Identifier (LocType = 2): 64 bit ILA locator 574 o 32 bit index (LocType = 3): 32 bit index into an locator table 576 o 64 bit index (LocType = 4): 64 bit index into an locator table 578 For the table index types it is assumed that a table mapping index to 579 and locator is shared with ILA forwarding nodes and hosts. 581 5 Operation 583 5.1 Version negotiation 585 The first message sent by each side of an ILAMP connection is a Hello 586 message. Hello messages contain the minimum and maximum versions of 587 ILAMP supported. The minimum and maximum values form an inclusive 588 range. 590 When a host receives and ILAMP Hello it determines which version is 591 negotiated. The negotiated version is the maximum version number 592 support by both sides. For instance, if a node advertises a minimum 593 version of 0 and maximum of 1 and receives a peer Hello message with 594 a minimum version of 0 and maximum of 2; then the negotiated version 595 is 1 since that is the greatest version supported by both sides. The 596 peer host will also determine that 1 is the negotiated version. 598 If there is no common version supported between the peers, that is 599 their supported version ranges are disjoint, then version negotiation 600 fails. The connection MUST be terminated and error message SHOULD be 601 logged. 603 If both sides set the router bit or both clear the router bit in a 604 Hello message, then this is an error and the connection MUST be 605 terminated and error message SHOULD be logged. Both sides cannot have 606 the same role in an ILAMP session. 608 5.2 Populating an ILA cache 610 ILA forwarding nodes and ILA hosts maintain a cache of identifier to 611 locator mappings. There are three means that this cache can be 612 populated by ILAMP: 614 o ILA redirect 616 o Mapping request/reply 618 o Push mappings 620 ILA redirects are RECOMMNDED to be the primary means of obtaining 621 mapping information. Request/reply and push mappings may be used in 622 limited circumstances, however generally these techniques don't 623 scale. 625 Note that forwarding nodes and hosts do not hold packets that are 626 pending mapping resolution. If a node does not have a mapping for a 627 destination in its cache then packet is forwarded in the network. The 628 packet should be translated by an ILA router and sent to the proper 629 destination node. 631 5.2.1 ILA Redirects 633 A mapping router can send ILA redirects in conjunction with 634 forwarding packets. Redirects are sent to ILA forwarding nodes and 635 ILA hosts in order to inform them of a direct ILA path. A redirect is 636 sent to the upstream ILA forwarding node or host of the source which 637 is determined by an ILA lookup on the source address of the packet 638 being forwarded. The found locator is used to infer an address of the 639 ILA forwarding node or host. For instance, the address of the 640 forwarding node might be ::1 where is a sixty-four 641 bit prefix and 0:0:0:1 is reserved as a special identifier. Note that 642 this technique assumes a symmetric path towards the source. If a 643 redirect is sent then the received packet that motivated the redirect 644 MUST be ILA translated and forwarded by the router. 646 5.2.1.1 Proactive push with redirect 648 In addition to sending an ILA redirect to the ILA forwarding node or 649 host, a mapping router MAY send an ILA push to the ILA forwarding 650 node or host of the destination to inform it of the identifier to 651 locator mapping for the source address in a packet. This is an 652 optimization to push the ILA translation that will be used in the 653 reverse direction of the communications. In order to do this, the 654 mapping router performs an ILA lookup on the source address (which 655 should already be done to perform the redirect). An ILA push message 656 is then sent to the forwarding node or host based on its locator. 658 5.2.1.2 Redirect rate limiting 660 A mapping router SHOULD rate limit the number of redirects it sends 661 to a forwarding node or host for each redirected address. The rate 662 limit SHOULD be configurable. The default SHOULD be that no more than 663 one redirect is sent every one half of the minimum identifier timeout 664 being used. The minimum rate limit SHOULD be to send no more than one 665 redirect per second per redirected identifier. If a mapping change is 666 detected the rate limiting SHOULD be reset so that redirects for a 667 new mapping can be sent immediately. 669 5.2.2 Map request/reply 671 A forwarding node or host may send a map request message to obtain 672 mapping information for a locator. If the receiving mapping router 673 has the mapping information it responds with a map information 674 message. If the mapping router does not have a mapping entry for the 675 requested identifier it MAY reply with in all zeros locator (LocType 676 = 2 and 64 bit locator is all zeroes). 678 Map requests are NOT RECOMMENDED to be used to populate entries in 679 the cache table that are not present. The problem with this technique 680 is that an ILA forwarding node or host may generate a map request for 681 each new destination that it gets from a downstream end host. A 682 downstream end host could launch a Denial of Service (DOS) attack 683 whereby it sends packets with random destination addresses that 684 requires a mapping looking. In the worse case scenario the mapping 685 router would send a map request for every packet received. Rate 686 limiting the sending of map requests does not mitigate the problem 687 since that would prevent the cache from getting mappings for 688 legitimate destinations. 690 5.2.3 Push mappings 692 A mapping router may push mappings to an ILA forwarding node or host 693 without being requested to do so. This mechanism could be used to 694 pre-populate an ILA cache. Pre-populating the cache might be done if 695 the network has a very small number of identifiers or there are a set 696 of identifiers that are likely to be used for forwarding in most ILA 697 forwarding nodes and hosts (identifiers for common services in the 698 network for instance). When a mapping router detects a changed 699 mapping, the locator changes for instance, the new mapping can be 700 pushed to the ILA nodes and hosts. 702 The push model is NOT RECOMMENDED as a primary means to populate an 703 ILA cache since this does not scale. Conceivably, one could keep 704 track of all ILA mappings and to which nodes the mapping information 705 was provided. When a mapping changes, mapping information could be 706 sent to those nodes that expressed interest. Such a scheme will not 707 scale in deployments that have many mappings. 709 5.3 Cache maintenance 711 5.3.1 Timeouts 713 A node SHOULD apply a timeout for the mapping entry using either the 714 default timeout or record timeout if one was received in an extended 715 map information message. If the timeout fires then the mapping entry 716 is removed. Subsequent packets may cause a mapping router to send a 717 redirect so that the mapping entry gets repopulated in the cache. 719 5.3.2 Cache refresh 721 In order to avoid cycling a mapping entry with a redirect for a 722 mapping that times out, a node MAY try to refresh the mapping before 723 timeout. This should only be done if the cache entry has been used to 724 forward a packet during the timeout interval. 726 A cache refresh is performed by sending a map request for an 727 identifier before its cache entry expires. If a map information 728 messages is received for the identifier then the timeout can be reset 729 and there are no other side effects. 731 5.3.3 Cache timeout values 733 The RECOMMENDED default timeout for identifiers is one minute. If a 734 node sends a map request to refresh a mapping, the RECOMMENDED 735 default is to send the request ten seconds before the the mapping 736 expires. 738 5.4 ILA forwarding node and host receive processing 740 If an ILA forwarding node or host receives an ILA addressed packet 741 with its locator it will check its local mapping database to 742 determine if the identifier is local. If the identifier is local, a 743 forwarding node will forward the packet to its destination after ILA 744 to SIR address translation has been done on the packet's destination 745 address. Similarly, an ILA host will receive the packet into it's 746 local stack after ILA to SIR address translation. 748 If the identifier is not local then the ILA forwarding node or host 749 will perform ILA to SIR address translation on the destination 750 address and forward the packet into the network. This may happen if 751 an end node has moved to be attached to a different ILA forwarding 752 node in host and the new locator has not yet been propagated to all 753 ILA nodes. The packet should traverse a mapping router which can send 754 an ILA redirect back the source's ILA forwarding node or host as 755 described above. 757 When a node migrates its point of attachment from one forwarding node 758 or host to another, the local mapping on the old node is removed so 759 that any packets that are received and destined to the migrated 760 identifier are re-injected with a SIR address as described above. A 761 "negative" mapping with timeout may also be set ensure that the node 762 is able to infer the SIR address from a destination address (e.g. 763 would be needed with foreign identifiers). 765 5.5 Locator unreachable handling 767 When connectivity to a locator is loss the mapping system should 768 detect this. A locator unreachable message MAY be sent by an ILA 769 router to ILA forwarding nodes or hosts informing them that a locator 770 is no longer reachable. Each forwarding node or host SHOULD remove 771 any cache entries using that locator and MAY send a map request for 772 the affected identifiers. 774 5.6 Control Connections 776 ILA nodes and routers must create ILAMP connections to all the 777 mapping routers that might provide routing information. In a simple 778 network there may be just one mapping router to connect to. In a more 779 complex network with ILA routers for sharded and replicated mapping 780 system database there may be many. A list of ILA routers to connect 781 to is provided to each ILA forwarding node and host. This list could 782 be provided by configuration, a shared database, or an external 783 protocol to ILAMP. 785 Conceivably, the number of mapping routers in a network that might 786 report mapping information to a host could be quite large (into the 787 thousands). If managing a large number of connections at the ILA 788 forwarding nodes or hosts is problematic, ILA mapping router proxies 789 could be used that consolidate connections as illustrated below: 791 +-------+ +-------+ +-------+ +-------+ +-------+ 792 |ILA-MR | | ILA-MR| | ILA-MR| | ILA-MR| | ILA-MR| 793 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 794 | | | | | 795 | +-+------------+-------------+-+ | 796 +----------+ ILA-R +----------+ 797 | PROXY | 798 +----------+ +----------+ 799 | +-+------------+-------------+-+ | 800 | | | | | 801 +---+---+ +---+---+ +---+---+ +---+---+ +-------+ 802 | ILA-N | | ILA-N | | ILA-H | | ILA-N | | ILA-N | 803 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 805 In the above diagram a single ILA mapping router proxy serves five 806 ILA routers and five ILA forwarding nodes and nodes. The proxy 807 creates one connection to each router and each ILA forwarding node 808 and host creates one connection to the proxy. 810 5.7 Protocol errors 812 If a protocol error is encountered in processing ILAMP messages a 813 peer MUST terminate the connection. It SHOULD log the error and MAY 814 attempt to restart the connection. There are no error messages 815 defined in ILAMP. 817 Protocol errors include mismatch of length for given data, reserved 818 bit not set to zero, unknown identifier type or locator types, 819 unknown type, unknown sub-type, and loss of message synchronization 820 in a TCP stream. Note that if the end of a message does not end on 821 field or record boundary this also considered a protocol error. 823 6 Security Considerations 825 ILAMP must have protection against message forgery. In particular 826 secure redirects and mapping information message are required to 827 prevent and attacked from spoofing messages and illegitimately 828 redirecting packets. This security is provided by using TCP 829 connections so that origin of the messages is never ambiguous. 831 Transport Layer Security (TLS) [RFC5246] MAY be used to provide 832 secrecy, authentication, and integrity check for ILAMP messages. 834 The TCP Authentication Option [RFC5925] MAY be used to provide 835 authentication for ILAMP messages. 837 7 IANA Considerations 839 8 References 841 8.1 Normative References 843 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 844 (IPv6) Specification", STD 86, RFC 8200, DOI 845 10.17487/RFC8200, July 2017, . 848 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 849 Architecture", RFC 4291, February 2006. 851 [ILA] Herbert, T., and Lapukhov, P., "Identifier Locator 852 Addressing for IPv6" draft-herbert-intarea-ila-00 854 8.2 Informative References 856 [RFC5246]] Dierks, T. and E. Rescorla, "The Transport Layer Security 857 (TLS) Protocol Version 1.2", RFC 5246, DOI 858 10.17487/RFC5246, August 2008, . 861 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 862 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 863 June 2010, . 865 [BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA 866 mapping information" draft-lapukhov-bgp-ila-afi-02 868 Author's Address 870 Tom Herbert 871 Quantonium 872 Santa Clara, CA 873 USA 875 Email: tom@quantonium.net