INTERNET-DRAFT T. Herbert Intended Status: Standard Quantonium Expires: June 2018 December 21, 2017 Identifier Locator Addressing Mapping Protocol draft-herbert-ila-ilamp-00 Abstract Identifier-locator protocols rely on a mapping system that is able to map identifiers to locators. ILA nodes that perform ILA translations need to access the mapping system via a protocol. This document specifies the ILA Mapping Protocol that is used by ILA forwarding nodes and hosts to populate and maintain a cache of ILA mappings. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents T. Herbert Expires June 24, 2018 [Page 1] INTERNET DRAFT draft-herbert-ila-ilamp (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Functional components . . . . . . . . . . . . . . . . . . . 5 2.2 ILA forwarding nodes and hosts . . . . . . . . . . . . . . . 5 2.2.1 ILA forwarding nodes . . . . . . . . . . . . . . . . . . 5 2.2.2 ILA hosts . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 ILA address to SIR address translation . . . . . . . . . 5 2.2.4 ILA Forwarding . . . . . . . . . . . . . . . . . . . . . 5 2.3 ILA routers . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Forwarding routers . . . . . . . . . . . . . . . . . . . 6 2.3.2 Mapping routers . . . . . . . . . . . . . . . . . . . . 6 2.3.3 ILA router synchronization . . . . . . . . . . . . . . . 7 3 ILA Mapping Protocol . . . . . . . . . . . . . . . . . . . . . 7 3.1 Common header format . . . . . . . . . . . . . . . . . . . . 8 3.2 Hello messages . . . . . . . . . . . . . . . . . . . . . . . 8 4 ILAMP Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Map request . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Map information . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Extended map information . . . . . . . . . . . . . . . . . . 11 4.4 Locator unreachable . . . . . . . . . . . . . . . . . . . . 12 4.5 Identifier and locator types . . . . . . . . . . . . . . . . 13 4.5.1 Identifier types . . . . . . . . . . . . . . . . . . . . 13 4.5.2 Locator types . . . . . . . . . . . . . . . . . . . . . 13 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Version negotiation . . . . . . . . . . . . . . . . . . . . 14 5.2 Populating an ILA cache . . . . . . . . . . . . . . . . . . 14 5.2.1 ILA Redirects . . . . . . . . . . . . . . . . . . . . . 15 5.2.1.1 Proactive push with redirect . . . . . . . . . . . . 15 5.2.1.2 Redirect rate limiting . . . . . . . . . . . . . . . 15 5.2.2 Map request/reply . . . . . . . . . . . . . . . . . . . 15 5.2.3 Push mappings . . . . . . . . . . . . . . . . . . . . . 16 5.3 Cache maintenance . . . . . . . . . . . . . . . . . . . . . 16 5.3.1 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.2 Cache refresh . . . . . . . . . . . . . . . . . . . . . 16 5.3.3 Cache timeout values . . . . . . . . . . . . . . . . . . 17 5.4 ILA forwarding node and host receive processing . . . . . . 17 5.5 Locator unreachable handling . . . . . . . . . . . . . . . . 17 T. Herbert Expires June 24, 2018 [Page 2] INTERNET DRAFT draft-herbert-ila-ilamp 5.6 Control Connections . . . . . . . . . . . . . . . . . . . . 18 5.7 Protocol errors . . . . . . . . . . . . . . . . . . . . . . 18 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 8.2 Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 T. Herbert Expires June 24, 2018 [Page 3] INTERNET DRAFT draft-herbert-ila-ilamp 1 Introduction The ILA Mapping Protocol (ILAMP) is a control plane protocol that provides ILA nodes mapping information. ILA [ILA] nodes that perform ILA translation rely on a mapping system to provide identifier to locator mappings. There are two levels of mapping protocols to be defined: one used by ILA routers that require the full set of ILA mappings for a domain, and one used by ILA nodes that maintain a caches of mappings. The ILA mapping system is effectively a key/value database that maps identifiers to locators. The protocol for sharing mapping information amongst ILA routers, nodes that maintain a full table of mappings, can thus be a database. A database schema for the ILA mapping system will be described in a separate document. ILA separates the control plane from the data plane, so alternative control plane protocols may be used with a common data plane. For instance, BGP could be used as a mapping system protocol [ILABGP]. 2 Reference topology This section provides a reference topology forILA. The topology is general however can be adapted to specific ILA use cases such as data center virtualization and mobility networks. Internet | +-----------------+ | ILA-FR | |Forwarding router| +--------+--------+ +------------+ _____|_____ +------------+ | ILA-MR | ( Shared ) | ILA-MR | | IMP router +-------( Database )-------+ IMP router | +------+-----+ (___________) +------+-----+ | | +-------+--+----------+ +----------+--+-------+ | | | | | | +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +-------+ | ILA-N | | ILA-N | | ILA-H | | ILA-N | | ILA-N | | ILA-H | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | | | | End hosts End hosts End hosts End hosts T. Herbert Expires June 24, 2018 [Page 4] INTERNET DRAFT draft-herbert-ila-ilamp 2.1 Functional components There are four types of functional nodes in the ILA architecture: ILA-N: ILA forwarding nodes ILA-H: ILA hosts ILA-FR: ILA forwarding routers ILA-MR: ILA mapping routers 2.2 ILA forwarding nodes and hosts 2.2.1 ILA forwarding nodes ILA forwarding nodes (ILA-N) are deployed in the network infrastructure towards the edges to provide caches for ILA forwarding. ILA forwarding nodes have two functions: ILA address to SIR address translation and ILA forwarding. As indicated in the reference topology, forwarding nodes may deployed near the point of device attachment (e.g. base station, eNodeB) of user devices (e.g. UEs). 2.2.2 ILA hosts ILA hosts (ILA-H) are end hosts that participate in ILA. These may be servers that provide ILA to work with virtualization techniques such as VMs or containers. ILA hosts perform the same functions as ILA forwarding nodes, however the source of packets is local to the same host so there are some optimizations that may be applied. 2.2.3 ILA address to SIR address translation ILA forwarding nodes and hosts perform ILA address to SIR address translation. This is a reverse ILA translation in order to restore the original addresses in a packet for delivery. Forwarding the packet on to the destination is done based on the SIR address. For instance, a forwarding node may map a SIR address to a layer 2 address of a directly attached device that has the SIR address. Note that this functionality is required somewhere in the path between the node that writes a locator into an address and the ultimate destination device. 2.2.4 ILA Forwarding An ILA forwarding node or host may perform ILA translation and forward packets directly to peer ILA nodes in the same domain. The T. Herbert Expires June 24, 2018 [Page 5] INTERNET DRAFT draft-herbert-ila-ilamp mappings for this are maintained in a working set cache. As a cache there must be methods to populate, evict, and timeout entries. A cache is considered an optimization so the system should be functional without its use (e.g. if the cache has no entries). 2.3 ILA routers ILA routers (denoted by ILA-R*) are deployed within the network infrastructure and collectively contain a database of all identifier to locator mappings in the domain, as well as all identifier group information for the domain. The database may be sharded across some number of ILA routers for scalability. ILA routers that maintain the database or a shard may be replicated for scalability and availability. ILA routers provide two main functions: ILA forwarding and mapping resolution. An ILA router may perform one or the other of these functions or may provide both at the same time. 2.3.1 Forwarding routers Forwarding routers (ILA-FR) perform ILA translation when packets enter a domain. A destination address of a packet that is a SIR address is translated to an ILA address. The process is that the router performs a lookup on the destination address in the mapping table and a locator is returned. The locator is written into the destination address of the packet (that is the high order sixty-four bits are overwritten with a locator). In the case of a sharded database being used, the high order bits of the identifier indicate the shard number. This is included in a routing prefix so that the packet is routed to an ILA router that contains the database for the relevant shard. 2.3.2 Mapping routers A mapping router (ILA-MR) provides ILA forwarding nodes and hosts mapping information. A mapping router may also perform ILA translations and forwarding. A mapping router implements ILAMP to communicate with ILA forwarding nodes and hosts. Mapping information is provided by a request/reply protocol, ILA redirects, or by a push mechanism. An ILA router that is performing mapping resolution will respond to mapping requests from ILA forwarding nodes or ILA hosts. The mapping request protocol allows a node to request the locator information for an identifier address. T. Herbert Expires June 24, 2018 [Page 6] INTERNET DRAFT draft-herbert-ila-ilamp A mapping router can send ILA redirects to ILA forwarding nodes and ILA hosts in order to inform them of a direct ILA path. A redirect is sent to the upstream ILA forwarding node or host of the source which is determined by an ILA lookup the source address. 2.3.3 ILA router synchronization ILA routers, both those that are forwarding and those that provide mapping resolution, must synchronize the contents of the database. This synchronization is done for each shard. When a change occurs to an identifier-locator mapping, for instance the locator for an identifier changes, the shard that contains the identifier must be synchronized in as little time to converge as possible. There are a number of options to use for implementing the ILA mapping system and router protocol. One option is to use a key/value database (such as a NoSQL database like Redis). The idea of the database is that each shard is a distributed database instance with some number of replicas. When a write is done in the database, the change is propagated throughout all of the replicas for the shard using the standard database replication mechanisms. Mapping information is written to the database using common database API and requires authenticated write permissions. Each ILA router can read the database for the associated shard to perform its function. The specifics of applying a database and a database schema for ILA will be provided in other documents. 3 ILA Mapping Protocol The ILA Mapping Protocol (ILAMP) is used between ILA forwarding nodes and ILA mapping routers. The purpose of the protocol is to populate and maintain the ILA mapping cache in forwarding nodes. ILAMP defines redirects, a request/response protocol, and a push mechanism to populate the mapping table. Unlike traditional routing protocols that run over UDP, this protocol is intended to be run over TCP. TCP provides reliability, statefulness implied by established connections, ordering, and security in the form of TLS. Secure redirects are facilitated by the use of TCP. ILAMP is used to send message between ILA routers and ILA forwarding nodes or hosts. The messages are sent over the TCP stream and must be delineated by a receiver. Different versions of ILAMP are allowed and the version used for communication is negotiated by Hello messages. T. Herbert Expires June 24, 2018 [Page 7] INTERNET DRAFT draft-herbert-ila-ilamp 3.1 Common header format All ILAMP messages begin with a two octet common header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the common header are: o Type: Indicates the type of message. A type 0 message is a hello message. Types greater than zero are interpreted per the negotiated version. o Length: Length of the message in octets. This includes the common header. The minimal length of a message is 2 octets and the maximum length is 1,048,575 octets. Following the two octet common header is variable length data that is specific to the version and type the message. 3.2 Hello messages Hello messages indicate the versions of ILAMP that a node supports. Hello message MUST be sent by each side as the first message in the connection. The format of an ILAMP Hello message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 4 |R| Rsvd | MinV | MaxV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the Hello message are: o Type = 0. This is indicates the type is a Hello message. o Router bit: Indicates the sender is an ILA router. If the sender is an ILA forwarding node or host this bit is cleared. o Rsvd: Reserved bits. Must be set to zero on transmit. o MinV: Minimum version number supported by the sending node. o MaxV: Maximum version number supported by the sending node. Version numbers are from 0 to 15. This document describes version 0 of ILAMP. T. Herbert Expires June 24, 2018 [Page 8] INTERNET DRAFT draft-herbert-ila-ilamp 4 ILAMP Version 0 The message types in version 0 of IMP are: o Map request (Type = 1) o Map information (Type = 2) o Extended map information (Type = 3) o Locator unreachable (Type = 4) 4.1 Map request A map request is sent by an ILA forwarding node or host to an ILA mapping router to request mapping information for a list of identifiers. The format of a map request is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Length | Rsvd | IDType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | | ~ Identifier ~ ent | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ The contents of the map request message are: o Type = 1. This is indicates the type is map request. o Length: Set to 4 plus the size of the identifier times the number of identifiers in the list. o Rsvd: Reserved bits. Must be set to zero when sending. o IDType: Identifier type. Specifies the identifier type. This also implies the length of each identifier in the request list. Identifier types are defined below. o Identifier: An identifier of type indicated by IDType. The size of an identifier is specified by the type. The Identifier field is repeated for each identifier in the list. The number of identifiers being requested is (message length - 4) / (identifier size). T. Herbert Expires June 24, 2018 [Page 9] INTERNET DRAFT draft-herbert-ila-ilamp 4.2 Map information Map information messages are sent by an ILA router to an ILA forwarding node or host. This message provides a list of identifier to locator mappings. The format of a map information message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Length | Rsvd |SubType|LocType| IDType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | | ~ Identifier ~ e | | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t | | | ~ Locator ~ | | |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the map information message are: o Type = 2. This is indicates the type is map information. o Length: Set to 4 plus the size of an identifier and locator times the number of identifier/locator pairs in the list. o Rsvd: Reserved bits. Must be set to zero when sending. o SubType: Specifies the reason that ILA-R sent this message. Sub types are o 0: Redirect o 1: Map reply to a map request o 2: Push map information o LocType: Locator type. Specifies the locator type. This also implies the length of each locator in the list. Locator types are defined below. o IDType: Identifier type. Specifies the identifier type. This also implies the length of each identifier in the list. Identifier types are defined below. o Identifier: An identifier of type indicated by IDType. The size of an identifier is specified by the type. o Locator: A locator of type indicated by LocType. The size of a T. Herbert Expires June 24, 2018 [Page 10] INTERNET DRAFT draft-herbert-ila-ilamp locator is specified by the type. The Identifier/Locator pair is repeated for each mapping being reported in the list. The number of identifiers being requested is (message length - 4) / (identifier size + locator size). 4.3 Extended map information An extended locator map information message is sent by an ILA router to associate more than one locator with an identifier as well as providing an expiration time for an identifier locator mapping and additional locator specific attributes. The format of an extended map information is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Length | Rsvd |SubType|LocType|IDType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ | | | ~ Identifier ~ | | | r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e | Num locator | Record timeout | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ o | Prio | Rsvd | Weight | Rsvd | e r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t d | | t | ~ Locator ~ | | | |/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+ The contents of the map reply message are: o Type = 3. This indicates an extended map information message o Length: Set to 4 plus the sum of sizes for each identifier record in the list. o Rsvd: Reserved bits. Must be set to zero when sending. o SubType: Specifies the reason that an ILA router sent this messages. Sub types are: o 0: Map reply to a map request o 1: Redirect o 2: Push map information T. Herbert Expires June 24, 2018 [Page 11] INTERNET DRAFT draft-herbert-ila-ilamp o LocType: Locator type. Specifies the locator type. This also implies the length of each locator in the list. Locator types are defined below. o IDType: Identifier type. Specifies the identifier type. This also implies the length of each identifier in the list. Identifier types are defined below. o Num locator: Number of locators being reported for an identifier. o Record timeout: The time to live for the identifier information in seconds. A value of zero indicates the default is used. o Priority: Relative priority of a locator. Locators with higher priority values have preference to be used. Locators that have the same priority may be used for load balancing. o Weight: Relative weights assigned to each locator. In the case that locators have the same priority the weights are used to control how traffic is distributed. A weight of zero indicates no weight and the mapping is not used unless all locators for the same priority have a weight of zero. o Locator: A locator of type specified in LocType. The identifier record is repeated for each mapping being reported and the locator entry is repeated for each locator being reported for an identifier. The total number of identifiers being reported is determined by parsing the message. 4.4 Locator unreachable A locator unreachable message is sent by an ILA router to ILA forwarding node or host in the event that a locator or locators are known to no longer be reachable. The format of a locator unreachable message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Length | Rsvd |LocType| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | | ~ Locator ~ ent | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ The contents of the locator ureachable message are: o Type = 4. This is indicates the type is a locator unreachable T. Herbert Expires June 24, 2018 [Page 12] INTERNET DRAFT draft-herbert-ila-ilamp message. o Length: Set to 4 plus the size of the locator times the number of locators in the list. o Rsvd: Reserved bits. Must be set to zero when sending. o LocType: Locator type. Specifies the locator type. This also implies the length of each locator in the list. Locator types are defined below. o Locator: A locator of type indicated by LocType. The size of a locator is specified by the type. The Locator field is repeated for each locator in the list. The number of locators being reported is (message length - 4) / (locator size). 4.5 Identifier and locator types 4.5.1 Identifier types Identifier types used in IDType fields of ILAMP messages are: o IPv6 address (IDType = 1): 128 bit IPv6 address o ILA Identifier (IDType = 2): 64 bit ILA identifier o 32 bit index (IDType = 3): 32 bit index into an identifier table o 64 bit index (IDType = 4): 64 bit index into an identifier table For the table index types it is assumed that a table mapping index to and identifier is shared with ILA forwarding nodes and hosts. 4.5.2 Locator types Locator types used in LocType fields of ILAMP messages are: o IPv6 address (LocType = 1): 128 bit IPv6 address o ILA Identifier (LocType = 2): 64 bit ILA locator o 32 bit index (LocType = 3): 32 bit index into an locator table o 64 bit index (LocType = 4): 64 bit index into an locator table For the table index types it is assumed that a table mapping index to T. Herbert Expires June 24, 2018 [Page 13] INTERNET DRAFT draft-herbert-ila-ilamp and locator is shared with ILA forwarding nodes and hosts. 5 Operation 5.1 Version negotiation The first message sent by each side of an ILAMP connection is a Hello message. Hello messages contain the minimum and maximum versions of ILAMP supported. The minimum and maximum values form an inclusive range. When a host receives and ILAMP Hello it determines which version is negotiated. The negotiated version is the maximum version number support by both sides. For instance, if a node advertises a minimum version of 0 and maximum of 1 and receives a peer Hello message with a minimum version of 0 and maximum of 2; then the negotiated version is 1 since that is the greatest version supported by both sides. The peer host will also determine that 1 is the negotiated version. If there is no common version supported between the peers, that is their supported version ranges are disjoint, then version negotiation fails. The connection MUST be terminated and error message SHOULD be logged. If both sides set the router bit or both clear the router bit in a Hello message, then this is an error and the connection MUST be terminated and error message SHOULD be logged. Both sides cannot have the same role in an ILAMP session. 5.2 Populating an ILA cache ILA forwarding nodes and ILA hosts maintain a cache of identifier to locator mappings. There are three means that this cache can be populated by ILAMP: o ILA redirect o Mapping request/reply o Push mappings ILA redirects are RECOMMNDED to be the primary means of obtaining mapping information. Request/reply and push mappings may be used in limited circumstances, however generally these techniques don't scale. Note that forwarding nodes and hosts do not hold packets that are pending mapping resolution. If a node does not have a mapping for a T. Herbert Expires June 24, 2018 [Page 14] INTERNET DRAFT draft-herbert-ila-ilamp destination in its cache then packet is forwarded in the network. The packet should be translated by an ILA router and sent to the proper destination node. 5.2.1 ILA Redirects A mapping router can send ILA redirects in conjunction with forwarding packets. Redirects are sent to ILA forwarding nodes and ILA hosts in order to inform them of a direct ILA path. A redirect is sent to the upstream ILA forwarding node or host of the source which is determined by an ILA lookup on the source address of the packet being forwarded. The found locator is used to infer an address of the ILA forwarding node or host. For instance, the address of the forwarding node might be ::1 where is a sixty-four bit prefix and 0:0:0:1 is reserved as a special identifier. Note that this technique assumes a symmetric path towards the source. If a redirect is sent then the received packet that motivated the redirect MUST be ILA translated and forwarded by the router. 5.2.1.1 Proactive push with redirect In addition to sending an ILA redirect to the ILA forwarding node or host, a mapping router MAY send an ILA push to the ILA forwarding node or host of the destination to inform it of the identifier to locator mapping for the source address in a packet. This is an optimization to push the ILA translation that will be used in the reverse direction of the communications. In order to do this, the mapping router performs an ILA lookup on the source address (which should already be done to perform the redirect). An ILA push message is then sent to the forwarding node or host based on its locator. 5.2.1.2 Redirect rate limiting A mapping router SHOULD rate limit the number of redirects it sends to a forwarding node or host for each redirected address. The rate limit SHOULD be configurable. The default SHOULD be that no more than one redirect is sent every one half of the minimum identifier timeout being used. The minimum rate limit SHOULD be to send no more than one redirect per second per redirected identifier. If a mapping change is detected the rate limiting SHOULD be reset so that redirects for a new mapping can be sent immediately. 5.2.2 Map request/reply A forwarding node or host may send a map request message to obtain mapping information for a locator. If the receiving mapping router has the mapping information it responds with a map information message. If the mapping router does not have a mapping entry for the T. Herbert Expires June 24, 2018 [Page 15] INTERNET DRAFT draft-herbert-ila-ilamp requested identifier it MAY reply with in all zeros locator (LocType = 2 and 64 bit locator is all zeroes). Map requests are NOT RECOMMENDED to be used to populate entries in the cache table that are not present. The problem with this technique is that an ILA forwarding node or host may generate a map request for each new destination that it gets from a downstream end host. A downstream end host could launch a Denial of Service (DOS) attack whereby it sends packets with random destination addresses that requires a mapping looking. In the worse case scenario the mapping router would send a map request for every packet received. Rate limiting the sending of map requests does not mitigate the problem since that would prevent the cache from getting mappings for legitimate destinations. 5.2.3 Push mappings A mapping router may push mappings to an ILA forwarding node or host without being requested to do so. This mechanism could be used to pre-populate an ILA cache. Pre-populating the cache might be done if the network has a very small number of identifiers or there are a set of identifiers that are likely to be used for forwarding in most ILA forwarding nodes and hosts (identifiers for common services in the network for instance). When a mapping router detects a changed mapping, the locator changes for instance, the new mapping can be pushed to the ILA nodes and hosts. The push model is NOT RECOMMENDED as a primary means to populate an ILA cache since this does not scale. Conceivably, one could keep track of all ILA mappings and to which nodes the mapping information was provided. When a mapping changes, mapping information could be sent to those nodes that expressed interest. Such a scheme will not scale in deployments that have many mappings. 5.3 Cache maintenance 5.3.1 Timeouts A node SHOULD apply a timeout for the mapping entry using either the default timeout or record timeout if one was received in an extended map information message. If the timeout fires then the mapping entry is removed. Subsequent packets may cause a mapping router to send a redirect so that the mapping entry gets repopulated in the cache. 5.3.2 Cache refresh In order to avoid cycling a mapping entry with a redirect for a mapping that times out, a node MAY try to refresh the mapping before T. Herbert Expires June 24, 2018 [Page 16] INTERNET DRAFT draft-herbert-ila-ilamp timeout. This should only be done if the cache entry has been used to forward a packet during the timeout interval. A cache refresh is performed by sending a map request for an identifier before its cache entry expires. If a map information messages is received for the identifier then the timeout can be reset and there are no other side effects. 5.3.3 Cache timeout values The RECOMMENDED default timeout for identifiers is one minute. If a node sends a map request to refresh a mapping, the RECOMMENDED default is to send the request ten seconds before the the mapping expires. 5.4 ILA forwarding node and host receive processing If an ILA forwarding node or host receives an ILA addressed packet with its locator it will check its local mapping database to determine if the identifier is local. If the identifier is local, a forwarding node will forward the packet to its destination after ILA to SIR address translation has been done on the packet's destination address. Similarly, an ILA host will receive the packet into it's local stack after ILA to SIR address translation. If the identifier is not local then the ILA forwarding node or host will perform ILA to SIR address translation on the destination address and forward the packet into the network. This may happen if an end node has moved to be attached to a different ILA forwarding node in host and the new locator has not yet been propagated to all ILA nodes. The packet should traverse a mapping router which can send an ILA redirect back the source's ILA forwarding node or host as described above. When a node migrates its point of attachment from one forwarding node or host to another, the local mapping on the old node is removed so that any packets that are received and destined to the migrated identifier are re-injected with a SIR address as described above. A "negative" mapping with timeout may also be set ensure that the node is able to infer the SIR address from a destination address (e.g. would be needed with foreign identifiers). 5.5 Locator unreachable handling When connectivity to a locator is loss the mapping system should detect this. A locator unreachable message MAY be sent by an ILA router to ILA forwarding nodes or hosts informing them that a locator is no longer reachable. Each forwarding node or host SHOULD remove T. Herbert Expires June 24, 2018 [Page 17] INTERNET DRAFT draft-herbert-ila-ilamp any cache entries using that locator and MAY send a map request for the affected identifiers. 5.6 Control Connections ILA nodes and routers must create ILAMP connections to all the mapping routers that might provide routing information. In a simple network there may be just one mapping router to connect to. In a more complex network with ILA routers for sharded and replicated mapping system database there may be many. A list of ILA routers to connect to is provided to each ILA forwarding node and host. This list could be provided by configuration, a shared database, or an external protocol to ILAMP. Conceivably, the number of mapping routers in a network that might report mapping information to a host could be quite large (into the thousands). If managing a large number of connections at the ILA forwarding nodes or hosts is problematic, ILA mapping router proxies could be used that consolidate connections as illustrated below: +-------+ +-------+ +-------+ +-------+ +-------+ |ILA-MR | | ILA-MR| | ILA-MR| | ILA-MR| | ILA-MR| +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ | | | | | | +-+------------+-------------+-+ | +----------+ ILA-R +----------+ | PROXY | +----------+ +----------+ | +-+------------+-------------+-+ | | | | | | +---+---+ +---+---+ +---+---+ +---+---+ +-------+ | ILA-N | | ILA-N | | ILA-H | | ILA-N | | ILA-N | +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ In the above diagram a single ILA mapping router proxy serves five ILA routers and five ILA forwarding nodes and nodes. The proxy creates one connection to each router and each ILA forwarding node and host creates one connection to the proxy. 5.7 Protocol errors If a protocol error is encountered in processing ILAMP messages a peer MUST terminate the connection. It SHOULD log the error and MAY attempt to restart the connection. There are no error messages defined in ILAMP. Protocol errors include mismatch of length for given data, reserved bit not set to zero, unknown identifier type or locator types, T. Herbert Expires June 24, 2018 [Page 18] INTERNET DRAFT draft-herbert-ila-ilamp unknown type, unknown sub-type, and loss of message synchronization in a TCP stream. Note that if the end of a message does not end on field or record boundary this also considered a protocol error. 6 Security Considerations ILAMP must have protection against message forgery. In particular secure redirects and mapping information message are required to prevent and attacked from spoofing messages and illegitimately redirecting packets. This security is provided by using TCP connections so that origin of the messages is never ambiguous. Transport Layer Security (TLS) [RFC5246] MAY be used to provide secrecy, authentication, and integrity check for ILAMP messages. The TCP Authentication Option [RFC5925] MAY be used to provide authentication for ILAMP messages. T. Herbert Expires June 24, 2018 [Page 19] INTERNET DRAFT draft-herbert-ila-ilamp 7 IANA Considerations 8 References 8.1 Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [ILA] Herbert, T., and Lapukhov, P., "Identifier Locator Addressing for IPv6" draft-herbert-intarea-ila-00 8.2 Informative References [RFC5246]] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA mapping information" draft-lapukhov-bgp-ila-afi-02 Author's Address Tom Herbert Quantonium Santa Clara, CA USA Email: tom@quantonium.net T. Herbert Expires June 24, 2018 [Page 20]