Skip to main content

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]