Identifier-locator addressing for IPv6
draft-herbert-intarea-ila-00
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Tom Herbert , Petr Lapukhov | ||
Last updated | 2017-10-19 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-herbert-intarea-ila-00
", RFC 6296, June 2011. [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. 8.2 Informative References [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012. [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002. [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003. Herbert Expires April 22, 2018 [Page 32] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 2016, <https://www.rfc- editor.org/info/rfc8014>. [GUE] Herbert, T., and Yong, L., "Generic UDP Encapsulation", draft-ietf-intarea-gue-04, work in progress. [GUESEC] Yong, L., and Herbert, T. "Generic UDP Encapsulation (GUE) for Secure Transport", draft-hy-gue-4-secure-transport- 03, work in progress 9 Acknowledgments The authors would like to thank Mark Smith, Lucy Yong, Erik Kline, Saleem Bhatti, Blake Matheny, Doug Porter, Pierre Pfister, and Fred Baker for their insightful comments for this draft; Roy Bryant, Lorenzo Colitti, Mahesh Bandewar, and Erik Kline for their work on defining and applying ILA; Kalyani Bogineni, Niranjan Avula, and Ratul Guha for insights regarding the mobility use case. Herbert Expires April 22, 2018 [Page 33] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 Appendix A: Communication scenarios This section describes the use of identifier-locator addressing in several scenarios. A.1 Terminology for scenario descriptions A formal notation for identifier-locator addressing with ILNP is described in [RFC6740]. We extend this to include for network virtualization cases. Basic terms are: A = IP Address I = Identifier L = Locator LUI = Locally unique identifier VNI = Virtual network identifier VA = An IPv4 or IPv6 virtual address VAX = An IPv6 networking identifier (IPv6 VA mapped to VAX) SIR = Prefix for standard identifier representation VNET = IPv6 prefix for a tenant (assumed to be globally routable) Iaddr = IPv6 address of an Internet host An ILA IPv6 address is denoted by L:I A SIR address with a locally unique identifier and SIR prefix is denoted by SIR:LUI A virtual identifier with a virtual network identifier and a virtual IPv4 address is denoted by VNI:VA An ILA IPv6 address with a virtual networking identifier for IPv4 would then be denoted L:(VNI:VA) The local and remote address pair in a packet or endpoint is denoted A,A An address translation sequence from SIR addresses to ILA addresses Herbert Expires April 22, 2018 [Page 34] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 for transmission on the network and back to SIR addresses at a receiver has notation: A,A -> L:I,A -> A,A A.2 Identifier objects Identifier-locator addressing is broad enough in scope to address many different types of networking entities. For the purposes of this section we classify these as "objects" and "tenant systems". Objects encompass uses where nodes are address by local unique identifiers (LUI). In the scenarios below objects are denoted by OBJ. Tenant systems are those associated with network virtualization that have virtual addresses (that is they are addressed by VNI:VA). In the scenarios below tenant systems are denoted by TS. A.3 Reference network for scenarios The figure below provides an example network topology with ILA addressing in use. In this example, there are four hosts in the network with locators L1, L2, L3, and L4. There three objects with identifiers O1, O2, and O3, as well as a common networking service with identifier S1. There are two virtual networks VNI1 and VNI2, and four tenant systems addressed as: VA1 and VA2 in VNI1, VA3 and VA4 in VNI2. The network is connected to the Internet via a gateway. ` ............. . . +-----------------+ . Internet . +-----------------+ | Host L1 | . . | Host L2 | | +-------------+ | ............. | +-------------+ | | | TS VNI1:VA1 | | | | | TS VNI1:VA2 | | | +-------------+ +---+ +-----+-----+ +---+ +-------------+ | | +-------------+ | | | Gateway | | | +-------------+ | | | OBJ O1 | | | +-----+-----+ | | | TS VNI2:VA3 | | | +-------------+ | | | | | +-------------+ | +-----------------+ | ............. | +-----------------+ +-----. .-----+ +-----------------+ . Underlay . +-----------------+ | Host L3 | +-----. Network .---+ | Host L4 | | +-------------+ | | ............. | | +-------------+ | | | OBJ O2 | | | | | | VM VNI2:VA4 | | | +-------------+ +---+ +-----| +-------------+ | | +-------------+ | | +-------------+ | | | OBJ O3 | | | | Serv. S1 | | | +-------------+ | | +-------------+ | +-----------------+ +-----------------+ Herbert Expires April 22, 2018 [Page 35] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 Several communication scenarios can be considered: 1) Object to object 2) Object to Internet 3) Internet to object 4) Tenant system to local service 5) Object to tenant system 6) Tenant system to Internet 7) Internet to tenant system 8) IPv4 tenant system to service 9) Tenant system to tenant system same virtual network using IPv6 10) Tenant system to tenant system in same virtual network using IPv4 11) Tenant system to tenant system in different virtual network using IPv6 12) Tenant system to tenant system in different virtual network using IPv4 13) IPv4 tenant system to IPv6 tenant system in different virtual networks 14) Non-local address to tenant system A.4 Scenario 1: Object to task The transport endpoints for object to object communication are the SIR addresses for the objects. When a packet is sent on the wire, the locator is set in the destination address of the packet. On reception the destination addresses is converted back to SIR representation for processing at the transport layer. If task T1 is communicating with task T2, the ILA translation sequence would be: SIR:O1,SIR:O2 -> // Transport endpoints on O1 SIR:O1,L3:O2 -> // ILA used on the wire SIR:O1,SIR:O2 // Received at O2 A.5 Scenario 2: Object to Internet Communication from an object to the Internet is accomplished through use of a SIR address (globally routable) in the source address of packets. No ILA translation is needed in this path. If object O1 is sending to an address Iaddr on the Internet, the packet addresses would be: SIR:O1,Iaddr A.6 Scenario 3: Internet to object Herbert Expires April 22, 2018 [Page 36] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 An Internet host transmits a packet to a task using an externally routable SIR address. The SIR prefix routes the packet to a gateway for the datacenter. The gateway translates the destination to an ILA address. If a host on the Internet with address Iaddr sends a packet to object O3, the ILA translation sequence would be: Iaddr,SIR:O3 -> // Transport endpoint at Iaddr Iaddr,L1:O3 -> // On the wire in datacenter Iaddr,SIR:O3 // Received at O3 A.7 Scenario 4: Tenant system to service A tenant can communicate with a datacenter service using the SIR address of the service. If TS VA1 is communicating with service S1, the ILA translation sequence would be: VNET:VA1,Saddr-> // Transport endpoints in TS SIR:(VNET:VA1):Saddr-> // On the wire SIR:(VNET:VA1):Saddr // Received at S1 Where VNET is the address prefix for the tenant and Saddr is the IPv6 address of the service. The ILA translation sequence in the reverse path, service to tenant system, would be: Saddr,SIR:(VNET:VA1) // Transport endpoints in S1 Saddr,L1:(VNET:VA1) // On the wire Saddr,VNET:VA1 // Received at the TS Note that from the point of view of the service task there is no material difference between a peer that is a tenant system versus one which is another task. A.8 Scenario 5: Object to tenant system An object can communicate with a tenant system through it's externally visible address. If object O2 is communicating with TS VA4, the ILA translation sequence would be: SIR:O2,VNET:VA4 -> // Transport endpoints at T2 SIR:O2,L4:(VNI2:VAX4) -> // On the wire Herbert Expires April 22, 2018 [Page 37] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 SIR:O2,VNET:VA4 // Received at TS A.9 Scenario 6: Tenant system to Internet Communication from a TS to the Internet assumes that the VNET for the TS is globally routable, hence no ILA translation would be needed. If TS VA4 sends a packet to the Internet, the addresses would be: VNET:VA4,Iaddr A.10 Scenario 7: Internet to tenant system An Internet host transmits a packet to a tenant system using an externally routable tenant prefix and address. The prefix routes the packet to a gateway for the datacenter. The gateway translates the destination to an ILA address. If a host on the Internet with address Iaddr is sending to TS VA4, the ILA translation sequence would be: Iaddr,VNET:VA4 -> // Endpoint at Iaddr Iaddr,L4:(VNI2:VAX4) -> // On the wire in datacenter Iaddr,VNET:VA4 // Received at TS A.11 Scenario 8: IPv4 tenant system to object A TS that is IPv4-only may communicate with an object using protocol translation. The object would be represented as an IPv4 address in the tenant's address space, and stateless NAT64 should be usable as described in [RFC6145]. If TS VA2 communicates with object O3, the ILA translation sequence would be: VA2,ADDR3 -> // IPv4 endpoints at TS SIR:(VNI1:VA2),L3:O3 -> // On the wire in datacenter SIR:(VNI1:VA2),SIR:O3 // Received at task VA2 is the IPv4 address in the tenant's virtual network, ADDR4 is an address in the tenant's address space that maps to the network service. The reverse path, task sending to a TS with an IPv4 address, requires a similar protocol translation. For object O3 communicate with TS VA2, the ILA translation sequence would be: Herbert Expires April 22, 2018 [Page 38] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 SIR:O3,SIR:(VNI1:VA2) -> // Endpoints at T4 SIR:O3,L2:(VNI1:VA2) -> // On the wire in datacenter ADDR4,VA2 // IPv4 endpoint at TS A.12 Tenant to tenant system in the same virtual network ILA may be used to allow tenants within a virtual network to communicate without the need for explicit encapsulation headers. A.12.1 Scenario 9: TS to TS in the same VN using IPV6 If TS VA1 sends a packet to TS VA2, the ILA translation sequence would be: VNET:VA1,VNET:VA2 -> // Endpoints at VA1 VNET:VA1,L2:(VNI1,VAX2) -> // On the wire VNET:VA1,VNET:VA2 -> // Received at VA2 A.12.2 Scenario 10: TS to TS in same VN using IPv4 For two tenant systems to communicate using IPv4 and ILA, IPv4/IPv6 protocol translation is done both on the transmit and receive. If TS VA1 sends an IPv4 packet to TS VA2, the ILA translation sequence would be: VA1,VA2 -> // Endpoints at VA1 SIR:(VNI1:VA1),L2:(VNI1,VA2) -> // On the wire VA1,VA2 // Received at VA2 Note that the SIR is chosen by an ILA node as an appropriate SIR prefix in the underlay network. Tenant systems do not use SIR address for this communication, they only use virtual addresses. A.13 Tenant system to tenant system in different virtual networks A tenant system may be allowed to communicate with another tenant system in a different virtual network. This should only be allowed with explicit policy configuration. A.13.1 Scenario 11: TS to TS in different VNs using IPV6 For TS VA4 to communicate with TS VA1 using IPv6 the translation sequence would be: VNET2:VA4,VNET1:VA1-> // Endpoint at VA4 VNET2:VA4,L1:(VNI1,VAX1)-> // On the wire VNET2:VA4,VNET1:VA1 // Received at VA1 Herbert Expires April 22, 2018 [Page 39] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 Note that this assumes that VNET1 and VNET2 are globally routable between the two virtual networks. A.13.2 Scenario 12: TS to TS in different VNs using IPv4 To allow IPv4 tenant systems in different virtual networks to communicate with each other, an address representing the peer would be mapped into each tenant's address space. IPv4/IPv6 protocol translation is done on transmit and receive. For TS VA4 to communicate with TS VA1 using IPv4 the translation sequence may be: VA4,SADDR1 -> // IPv4 endpoint at VA4 SIR:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire SADDR4,VA1 // Received at VA1 SADDR1 is the mapped address for VA1 in VA4's address space, and SADDR4 is the mapped address for VA4 in VA1's address space. A.13.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs Communication may also be mixed so that an IPv4 tenant system can communicate with an IPv6 tenant system in another virtual network. IPv4/IPv6 protocol translation is done on transmit. For TS VA4 using IPv4 to communicate with TS VA1 using IPv6 the translation sequence may be: VA4,SADDR1 -> // IPv4 endpoint at VA4 SIR:(VNI2:VA4),L1:(VNI1,VAX1)-> // On the wire SIR:(VNI2:VA4),VNET1:VA1 // Received at VA1 SADDR1 is the mapped IPv4 address for VA1 in VA4's address space. In the reverse direction, TS VA1 using IPv6 would communicate with TS VA4 with the translation sequence: VNET1:VA1,SIR:(VNI2:VA4) // Endpoint at VA1 VNET1:VA1,L4:(VNI2:VA4) // On the wire SADDR1,VA4 // Received at VA4 A.14 Scenario 14: Non-local address to tenant system A tenant system may have a global address that is non-local to the network. A host on the Internet or a tenant system may send packet to this address. The packet is forwarded by some means to a gateway or other ILA node (tunneling could be used to accomplish this). An ILA Herbert Expires April 22, 2018 [Page 40] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 node can crate a an ILA address for this using a non-local address identifier. For a node sending to a non-local address that is an address of task T2, the ILA translation sequence would be: SADDR,A // Endpoint at a host SADDR,L3:X // On the wire SADDR,A // Received by TS 2 Note that A is the non-local address, and X is is an identifier that maps to the non-local address. Appendix B: unique identifier generation The unique identifier type of ILA identifiers can address 2**60 objects (assuming the typed identifier format is used as described in section 4). This appendix describes some method to perform allocation of identifiers for objects to avoid duplicated identifiers being allocated. B.1 Globally unique identifiers method For small to moderate sized deployments the technique for creating locally assigned global identifiers described in [RFC4193] could be used. In this technique a SHA-1 digest of the time of day in NTP format and an EUI-64 identifier of the local host is performed. N bits of the result are used as the globally unique identifier. The probability that two or more of these IDs will collide can be approximated using the formula: P = 1 - exp(-N**2 / 2**(L+1)) where P is the probability of collision, N is the number of identifiers, and L is the length of an identifier. The following table shows the probability of a collision for a range of identifiers using a 60-bit length. Identifiers Probability of Collision 1000 4.3368*10^-13 10000 4.3368*10^-11 100000 4.3368*10^-09 1000000 4.3368*10^-07 Note that locally unique identifiers may be ephemeral, for instance a task may only exist for a few seconds. This should be considered when Herbert Expires April 22, 2018 [Page 41] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 determining the probability of identifier collision. B.2 Universally Unique Identifiers method For larger deployments, hierarchical allocation may be desired. The techniques in Universally Unique Identifier (UUID) URN ([RFC4122]) can be adapted for allocating unique object identifiers in sixty bits. An identifier is split into two components: a registrar prefix and sub-identifier. The registrar prefix defines an identifier block which is managed by an agent, the sub-identifier is a unique value within the registrar block. For instance, each host in a network could be an agent so that unique identifiers for objects could be created autonomously be the host. The identifier might be composed of a twenty-four bit host identifier followed by a thirty-six bit timestamp. Assuming that a host can allocate up to 100 identifiers per second, this allows about 21.8 years before wrap around. /* LUI identifier with host registrar and timestamp */ |3 bits|1| 24 bits | 36 bits | +------+-------------------+-------------------------------------+ | 0x1 |C| Host identifier | Timestamp Identifier | +----------------------------------------------------------------+ Appendix C: Datacenter task virtualization This section describes some details to apply ILA to virtualizing tasks in a datacenter. C.1 Address per task Managing the port number space for services within a datacenter is a nontrivial problem. When a service task is created, it may run on arbitrary hosts. The typical scenario is that the task will be started on some machine and will be assigned a port number for its service. The port number must be chosen dynamically to not conflict with any other port numbers already assigned to tasks on the same machine (possibly even other instances of the same service). A canonical name for the service is entered into a database with the host address and assigned port. When a client wishes to connect to the service, it queries the database with the service name to get both the address of an instance as well as its port number. Note that DNS is not adequate for the service lookup since it does not provide port numbers. With ILA, each service task can be assigned its own IPv6 address and therefore will logically be assigned the full port space for that Herbert Expires April 22, 2018 [Page 42] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 address. This a dramatic simplification since each service can now use a publicly known port number that does not need to unique between services or instances. A client can perform a lookup on the service name to get an IP address of an instance and then connect to that address using a well known port number. In this case, DNS is sufficient for directing clients to instances of a service. C.2 Job scheduling In the usual datacenter model, jobs are scheduled to run as tasks on some number of machines. A distributed job scheduler provides the scheduling which may entail considerable complexity since jobs will often have a variety of resource constraints. The scheduler takes these constraints into account while trying to maximize utility of the datacenter in terms utilization, cost, latency, etc. Datacenter jobs do not typically run in virtual machines (VMs), but may run within containers. Containers are mechanisms that provide resource isolation between tasks running on the same host OS. These resources can include CPU, disk, memory, and networking. A fundamental problem arises in that once a task for a job is scheduled on a machine, it often needs to run to completion. If the scheduler needs to schedule a higher priority job or change resource allocations, there may be little recourse but to kill tasks and restart them on a different machine. In killing a task, progress is lost which results in increased latency and wasted CPU cycles. Some tasks may checkpoint progress to minimize the amount of progress lost, but this is not a very transparent or general solution. An alternative approach is to allow transparent job migration. The scheduler may migrate running jobs from one machine to another. C.3 Task migration Under the orchestration of the job scheduler, the steps to migrate a job may be: 1) Stop running tasks for the job. 2) Package the runtime state of the job. The runtime state is derived from the containers for the jobs. 3) Send the runtime state of the job to the new machine where the job is to run. 4) Instantiate the job's state on the new machine. 5) Start the tasks for the job continuing from the point at which it was stopped. This model similar to virtual machine (VM) migration except that the runtime state is typically much less data-- just task state as Herbert Expires April 22, 2018 [Page 43] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 opposed to a full OS image. Task state may be compressed to reduce latency in migration. C.3.1 Address migration ILA facilitates address (specifically SIR address) migration between hosts as part of task migration or for other purposes. The steps in migrating an address might be: 1) Configure address on the target host. 2) Suspend use of the address on the old host. This includes handling established connections (see next section). A state may be established to drop packets or send ICMP destination unreachable when packets to the migrated address are received. 3) Update the identifier to locator mapping database. Depending on the control plane implementation this may include pushing the new mapping to hosts. 4) Communicating hosts will learn of the new mapping via a control plane either by participation in a protocol for mapping propagation or by the ILA resolution protocol. C.3.2 Connection migration When a task and its addresses are migrated between machines, the disposition of existing TCP connections needs to be considered. The simplest course of action is to drop TCP connections across a migration. Since migrations should be relatively rare events, it is conceivable that TCP connections could be automatically closed in the network stack during a migration event. If the applications running are known to handle this gracefully (i.e. reopen dropped connections) then this may be viable. For seamless migration, open connections may be migrated between hosts. Migration of these entails pausing the connection, packaging connection state and sending to target, instantiating connection state in the peer stack, and restarting the connection. From the time the connection is paused to the time it is running again in the new stack, packets received for the connection should be silently dropped. For some period of time, the old stack will need to keep a record of the migrated connection. If it receives a packet, it should either silently drop the packet or forward it to the new location. Herbert Expires April 22, 2018 [Page 44] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 Appendix D: Mobility in wireless networks ILA can be used in public wireless networks to provide a solution for mobility. Devices in a carrier network are referred to as User Equipment (UE) and can include smart phones, automobiles, and other IoT devices. UEs attach to provider network at base stations (eNodeB in carrier terminology). As the device moves, it may change it's point of attachment to a geographically close based station. A cellular network is composed of cells each of which has an eNodeB. A node may change cells several times over a time period. In order to provide seamless communications it is desirable that the existing connections of the device are preserved. ILA provides for this by assigning SIR addresses to UEs and deploying ILA routers in the network infrastructure. In a canonical architecture each base station (eNodeB) would have an ILA router, and there would be a number of ILA routers that serve as gateways between a provider's network and the Internet. When a host on the Internet sends to a UE's SIR address, a gateway ILA router will translate the address. The locator addresses the base station that is the current point of attachment. At the base station ILA router, the destination is translated back to a SIR address and delivered to a UE. A similar process can happen when two UEs in the network communicate. The wireless network use case is conceptually similar to network virtualization. In both scenarios, nodes have a point of attachment and can move to other points of attachment. The difference is that in network virtualization it is virtual machines that are mobile, in wireless networks it is real devices. The wireless use case has some unique properties: o These are often public networks so that privacy is a consideration. It is likely that devices may have many addresses assigned to promote privacy. o A single device might have many identifiers assigned to it. When a device moves, all of the identifiers must change to map to the same locator. o Devices move on their own accord so that mobility is unpredictable. o There are mostly real humans using devices so that human Herbert Expires April 22, 2018 [Page 45] INTERNET DRAFT draft-herbert-intarea-ila-00 October 19, 2017 identity and exposing geo location are concerns. Author's Address Tom Herbert Quantonium 4701 Patrick Henry Dr. Santa Clara, CA EMail: tom@herbertland.com Petr Lapukhov 1 Hacker Way Menlo Parck, CA EMail: petr@fb.com Herbert Expires April 22, 2018 [Page 46]