Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6740


Identifier-Locator Network Protocol (ILNP) Architectural Description

Part 2 of 3, p. 12 to 36
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 12 
3.  Architectural Changes Introduced by ILNP

   In this section, we describe the key changes that are made to the
   current Internet Architecture.  These key changes impact end-systems,
   rather than routers.

3.1.  Identifiers

   Identifiers, also called Node Identifiers (NIDs), are non-topological
   values that identify an ILNP node.  A node might be a physical node
   or a virtual node.  For example, a single physical device might
   contain multiple independent virtual nodes.  Alternately, a single
   virtual device might be composed from multiple physical devices.  In
   the case of a Multi-Level Secure (MLS) system [DIA] [DoD85] [DoD87]
   [RFC5570], each valid Sensitivity Label of that system might be a
   separate virtual node.

   A node MAY have multiple Identifier values associated with it, which
   MAY be used concurrently.

   In normal operation, when a node is responding to a received ILNP
   packet that creates a new network-layer session, the correct NID
   value to use for that network-layer session with that correspondent
   node will be learned from the received ILNP packet.

   In normal operation, when a node is initiating communication with a
   correspondent node, the correct I value to use for that session with
   that correspondent node will be learned either through the
   application-layer naming, through DNS name resolution, or through

Top      Up      ToC       Page 13 
   some alternative name resolution system.  Another option is an
   application may be able to select different I values directly -- as
   Identifiers are visible above the network layer via the transport

3.1.1.  Node Identifiers Are Immutable during a Session

   Once a Node Identifier (NID) value has been used to establish a
   transport-layer session, that Node Identifier value forms part of the
   end-to-end (invariant) transport-layer session state and so MUST
   remain fixed for the duration of that session.  This means, for
   example, that throughout the duration of a given TCP session, the
   Source Node Identifier and Destination Node Identifier values will
   not change.

   In normal operation, a node will not change its set of valid
   Identifier values frequently.  However, a node MAY change its set of
   valid Identifier values over time, for example, in an effort to
   provide identity obfuscation, while remaining subject to the
   architectural rule of the preceding paragraph.  When a node has more
   than one Node Identifier value concurrently, the node might have
   multiple concurrent ILNP sessions with some correspondent node, in
   which case Node Identifier values MAY differ between the different
   concurrent ILNP sessions.

3.1.2.  Syntax

   ILNP Identifiers have the same syntax as IPv6 interface identifiers
   [RFC4291], based on the EUI-64 format [IEEE-EUI], which helps with
   backwards compatibility.  There is no semantic equivalent to an ILNP
   Identifier in IPv4 or IPv6 today.

   The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6
   interface identifiers contains a bit indicating whether the value has
   global scope or local scope [IEEE-EUI] [RFC4291].  ILNP Identifiers
   have either global scope or local scope.  If they have global scope,
   they SHOULD be globally unique.

   Regardless of whether an Identifier is global scope or local scope,
   an Identifier MUST be unique within the scope of a given Locator
   value to which it is bound for a given ILNP session or packet flow.
   As an example, with ILNPv6, the ordinary IPv6 Neighbour Discovery
   (ND) processes ensure that this is true, just as ND ensures that no
   two IPv6 nodes on the same IPv6 subnetwork have the same IPv6 address
   at the same time.

Top      Up      ToC       Page 14 
   Both the IEEE EUI-64 specification and the Modified EUI-64 syntax
   also has a 'Group' bit [IEEE-EUI] [RFC4291].  For both ILNP node
   Identifiers and also IPv6 interface identifiers, this Group bit is
   set to 0.

3.1.3.  Semantics

   Unicast ILNP Identifier values name the node, rather than naming a
   specific interface on that node.  So ILNP Identifiers have different
   semantics than IPv6 interface identifiers.

3.2.  Locators

   Locators are topologically significant names, analogous to
   (sub)network routing prefixes.  The Locator names the IP subnetwork
   that a node is connected to.  ILNP neither prohibits nor mandates in-
   transit modification of Locator values.

   A host MAY have several Locators at the same time, for example, if it
   has a single network interface connected to multiple subnetworks
   (e.g., VLAN deployments on wired Ethernet) or has multiple interfaces
   each on a different subnetwork.  Locator values normally have Locator
   Preference Indicator (LPI) values associated with them.  These LPIs
   indicate that a specific Locator value has higher or lower preference
   for use at a given time.  Local LPI values may be changed through
   local policy or via management interfaces.  Remote LPI values are
   normally learned from the DNS, but the local copy of a remote LPI
   value might be modified by local policy relating to preferred paths
   or prefixes.

   Locator values are used only at the network layer.  Locators are not
   used in end-to-end transport state.  For example, Locators are not
   used in transport-layer session state or application-layer session
   state.  However, this does not preclude an end-system setting up
   local dynamic bindings for a single transport flow to multiple
   Locator values concurrently.

   The routing system only uses Locators, not Identifiers.  For unicast
   traffic, ILNP uses longest-prefix match routing, just as the IP
   Internet does.

   Section 4 below describes in more detail how Locators are used in
   forwarding and routing packets from a sending node on a source
   subnetwork to one or more receiving nodes on one or more destination

Top      Up      ToC       Page 15 
   A difference from earlier proposals [GSE] [8+8] is that, in normal
   operation, the originating host supplies both Source Locator and
   Destination Locator values in the packets it sends out.

   Section 4.3 describes packet forwarding in more detail, while Section
   4.4 describes packet routing in more detail.

3.2.1.  Locator Values Are Dynamic

   The ILNP architecture recognises that Locator values are
   topologically significant, so the set of Locator values associated
   with a node normally will need to change when the node's connectivity
   to the Internet topology changes.  For example, a mobile or
   multihomed node is likely to have connectivity changes from time to
   time, along with the corresponding changes to the set of Locator

   When a node using a specific set of Locator values changes one or
   more of those Locator values, then the node (1) needs to update its
   local knowledge of its own Locator values, (2) needs to inform all
   active Correspondent Nodes (CNs) of those changes to its set of
   Locator values so that ILNP session continuity is maintained, and (3)
   if it expects incoming connections the node also needs to update its
   Locator-related entries in the Domain Name System.  [RFC6741]
   describes the engineering and implementation details of this process.

3.2.2.  Locator Updates

   As Locator values can be dynamic, and they could change for a node
   during an ILNP session, correspondents need to be notified when a
   Locator value for a node changes for any existing ILNP session.  To
   enable this, a node that sees its Locator values have changed MUST
   send a Locator Update (LU) message to its correspondent nodes.  The
   details of this procedure are discussed in other ILNP documents --
   [RFC6741], [RFC6743], and [RFC6745].  (The change in Locator values
   may also need to be notified to DNS but that is discussed elsewhere.)

3.2.3.  Syntax

   ILNP Locators have the same syntax as an IP unicast routing prefix.

3.2.4.  Semantics

   ILNP unicast Locators have the same semantics as an IP unicast
   routing prefix, since they name a specific subnetwork.  ILNP neither
   prohibits nor requires in-transit modification of Locator values.

Top      Up      ToC       Page 16 
3.3.  IP Address and Identifier-Locator Vector (I-LV)

   Historically, an IP Address has been considered to be an atomic
   datum, even though it is recognised that an IP Address has an
   internal structure: the network prefix plus either the host ID (IPv4)
   or the interface identifier (IPv6).  However, this internal structure
   has not been used in end-system protocols; instead, all the bits of
   the IP Address are used.  (Additionally, in IPv4 the IPv4 subnet mask
   uses bits from the host ID, a further confusion of the structure,
   even thought it is an extremely useful engineering mechanism.)

   In ILNP, the IP Address is replaced by an "Identifier-Locator Vector"
   (I-LV).  This consists of a pairing of an Identifier value and a
   Locator value for that packet, written as [I, L].  All ILNP packets
   have Source Identifier, Source Locator, Destination Identifier, and
   Destination Locator values.  The I value of the I-LV is used by
   upper-layer protocols (e.g., TCP, UDP, SCTP), so needs to be
   immutable.  Locators are not used by upper-layer protocols (e.g.,
   TCP, UDP, SCTP).  Instead, Locators are similar to IP routing
   prefixes, and are only used to name a specific subnetwork.

   While it is possible to say that an I-LV is an approximation to an IP
   Address of today, it should be understood that an I-LV:

      a) is not an atomic datum, being a pairing of two data types, an
         Identifier and a Locator.

      b) has different semantics and properties to an IP Address, as is
         described in this document.

   In our discussion, it will be convenient sometimes to refer to an
   I-LV, but sometimes to refer only to an Identifier value, or only to
   a Locator value.

   ILNP packets always contain a source I-LV and a destination I-LV.

3.4.  Notation

   In describing how capabilities are implemented in ILNP, we will
   consider the differences in end-systems' state between IP and ILNP in
   order to highlight the architectural changes.

Top      Up      ToC       Page 17 
   We define a formal notation to represent the data contained in the
   transport-layer session state.  We define:

      A = IP Address
      I = Identifier
      L = Locator
      P = Transport-layer port number

   To differentiate the local and remote values for the above items, we
   also use suffixes, for example:

      _L = local
      _R = remote

   With IPv4 and IPv6 today, the invariant state at the transport-layer
   for TCP can be represented by the tagged tuple:

      <TCP: A_L, A_R, P_L, P_R>                               --- (1)

   Tag values that will be used are:

        IP   Internet Protocol
        ILNP Identifier-Locator Network Protocol
        TCP  Transmission Control Protocol
        UDP  User Datagram Protocol

   So, for example, with IP, a UDP packet would have the tagged tuple:

      <UDP: A_L, A_R, P_L, P_R>                               --- (2)

   A TCP segment carried in an IP packet may be represented by the
   tagged tuple binding:

      <TCP: A_L, A_R, P_L, P_R><IP: A_L, A_R>                 --- (3)

   and a UDP packet would have the tagged tuple binding:

      <UDP: A_L, A_R, P_L, P_R><IP: A_L, A_R>                 --- (4)

   In ILNP, the transport-layer state for TCP is:

      <TCP: I_L, I_R, P_L, P_R>                               --- (5)

   The binding for a TCP segment within an ILNP packet:

      <TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R>               --- (6)

Top      Up      ToC       Page 18 
   When comparing tuple expressions (3) and (6), we see that for IP, any
   change to network addresses impacts the end-to-end state, but for
   ILNP, changes to Locator values do not impact end-to-end state.  This
   provides end-system session state invariance, a key feature of ILNP
   compared to IP as it is used in some situations today.  ILNP adopts
   the end-to-end approach for its architecture [SRC84].  As noted
   previously, nodes MAY have more than one Locator concurrently, and
   nodes MAY change their set of active Locator values as required.

   While these documents do not include SCTP examples, the same notation
   can be used, simply substituting the string "SCTP" for the string
   "TCP" or the string "UDP" in the above examples.

3.5.  Transport-Layer State and Transport Pseudo-Headers

   In ILNP, protocols above the network layer do not use the Locator
   values.  Thus, the transport layer uses only the I values for the
   transport-layer session state (e.g., TCP pseudo-header checksum, UDP
   pseudo-header checksum), as is shown, for example, in expression (6)

   Additionally, from a practical perspective, while the I values are
   only used in protocols above the network layer, it is convenient for
   them to be carried in network packets, so that the namespace for the
   I values can be used by any transport-layer protocols operating above
   the common network layer.

3.6.  Rationale for This Document

   This document provides an architectural description of the core ILNP
   capabilities and functions.  It is based around the use of example
   scenarios so that practical issues can be highlighted.

   In some cases, illustrative suggestions and light discussion are
   presented with respect to engineering issues, but detailed discussion
   of engineering issues are deferred to other ILNP documents.

   The order of the examples presented below is intended to allow an
   incremental technical understanding of ILNP to be developed.  There
   is no other reason for the ordering of the examples listed below.

   Many of the descriptions are based on the use of an example site
   network as shown in Figure 3.1.

Top      Up      ToC       Page 19 
         site                         . . . .      +----+
        network                      .       .-----+ CN |
        . . . .      +------+ link1 .         .    +----+
       .       .     |      +------.           .
      .    D    .    |      |      .           .
      .         .----+ SBR  |      . Internet  .
      .  H      .    |      |      .           .
       .       .     |      +------.           .
        . . . .      +------+ link2 .         .
                                     .       .
                                      . . . .

           CN  = Correspondent Node
            D  = Device
            H  = Host
          SBR  = Site Border Router

      Figure 3.1: A Simple Site Network for ILNP Examples

   In some cases, hosts (H) or devices (D) act as end-systems within the
   site network, and communicate with (one or more) Correspondent Node
   (CN) instances that are beyond the site.

   Note that the figure is illustrative and presents a logical view.
   For example, the CN may itself be on a site network, just like H or

   Also, for formulating examples, we assume ILNPv6 is in use, which has
   the same packet header format (as viewed by routers) as IPv6, and can
   be seen as a superset of IPv6 capabilities.

   For simplicity, we assume that name resolution is via the deployed
   DNS, which has been updated to store DNS records for ILNP [RFC6742].

   Note that, from an engineering viewpoint, this does NOT mean that the
   DNS also has to be ILNP capable: existing IPv4 or IPv6 infrastructure
   can be used for DNS transport.

3.7.  ILNP Multicasting

   Multicast forwarding and routing are unchanged, in order to avoid
   requiring changes in deployed IP routers and routing protocols.
   ILNPv4 multicasting is the same as IETF Standards Track IPv4
   multicasting [RFC1112] [RFC3376].  ILNPv6 multicasting is the same as
   IETF Standards Track IPv6 multicasting [RFC4291] [RFC2710] [RFC3810].

Top      Up      ToC       Page 20 
4.  ILNP Basic Connectivity

   In this section, we describe basic packet forwarding and routing in
   ILNP.  We highlight areas where it is similar to current IP, and also
   where it is different from current IP.  We use examples in order to
   illustrate the intent and show the feasibility of the approach.

   For this section, in Figure 4.1, H is a fixed host in a simple site
   network, and CN is a remote Correspondent Node outside the site; H
   and CN are ILNP-capable, while the Site Border Router (SBR) does not
   need to be ILNP-capable.

         site                         . . . .      +----+
        network                      .       .-----+ CN |
        . . . .      +------+       .         .    +----+
       .       .     |      +------.           .
      .         .    |      |      .           .
      .         .----+ SBR  |      . Internet  .
      .  H      .    |      |      .           .
       .       .     |      |      .           .
        . . . .      +------+       .         .
                                     .       .
                                      . . . .

           CN  = Correspondent Node
            H  = Host
          SBR  = Site Border Router

      Figure 4.1: A Simple Site Network for ILNP Examples

4.1.  Basic Local Configuration

   This section uses the term "address management", in recognition of
   the analogy with capabilities present in IP today.  In this document,
   address management is about enabling hosts to attach to a subnetwork
   and enabling network-layer communication between and among hosts,
   also including:

      a) enabling identification of a node within a site.
      b) allowing basic routing/forwarding from a node acting as an end-

   If we consider Figure 4.1, imagine that host H has been connected to
   the site network.  Administratively, it needs at least one I value
   and one L value in order to be able to communicate.

Top      Up      ToC       Page 21 
   Today, local administrative procedures allocate IP Addresses, often
   using various protocol mechanisms (e.g., NETCONF-based router
   configuration, DHCP for IPv4, DHCP for IPv6, IPv6 Router
   Advertisements).  Similarly, local administrative procedures can
   allocate I and L values as required, e.g., I_H and L_H.  This may be
   through manual configuration.

   Additionally, if it is expected or desired that H might have incoming
   communication requests, e.g., it is a server, then the values I_H and
   L_H can be added to the relevant name services (e.g., DNS, NIS/YP),
   so that FQDN lookups for H resolve to the appropriate DNS resource
   records (e.g., NID, L32, L64, and LP [RFC6742]) for node H.

   From a network operations perspective, this whole process also can be
   automated.  As an example, consider that in Figure 3.1 the Site
   Border Router (SBR) is an IPv6-capable router and is connected via
   link1 to an ISP that supports IPv6.  The SBR will have been allocated
   one (or more) IPv6 prefixes that it will multicast using IPv6 Routing
   Advertisements (RAs) into the site network, e.g., prefix L_1.  L_1 is
   actually a local IPv6 prefix (/64), which is formed from an address
   assignment by the upstream ISP, according to [RFC3177] or [RFC6177].
   Host H will see these RAs, for example, on its local interface with
   name eth0, will be able to use that prefix as a Locator value, and
   will cache that Locator value locally.

   Also, node H can use the mechanism documented in either Section 2.5.1
   of [RFC4291], in [RFC3972], [RFC4581], [RFC4982], or in [RFC4941] in
   order to create a default I value (say, I_H), just as an IPv6 host
   can.  For DNS, the I_H and L_1 values may be pre-configured in DNS by
   an administrator who already has knowledge of these, or added to DNS
   by H using Secure DNS Dynamic Update [RFC3007] to add or update the
   correct NID and L64 records to DNS for the FQDN for H.

4.2.  I-L Communication Cache

   For the purposes of explaining the concept of operations, we talk of
   a local I-L Communication Cache (ILCC).  This is an engineering
   convenience and does not form part of the ILNP architecture, but is
   used in our examples.  More details on the ILCC can be found in
   [RFC6741].  The ILCC contains information that is required for the
   operation of ILNP.  This will include, amongst other things, the
   current set of valid Identifier and Locator values in use by a node,
   the bindings between them, and the bindings between Locator values
   and interfaces.

Top      Up      ToC       Page 22 
4.3.  Packet Forwarding

   When the SBR needs to send a packet to H, it uses local address
   resolution mechanisms to discover the bindings between interface
   addresses and currently active I-LVs for H.  For our example of
   Figure 3.1, IPv6 Neighbour Discovery (ND) can be used without
   modification, as the I-LV for ILNPv6 occupies the same bits as the
   IPv6 address in the IPv6 header.  For packets from H to SBR, the same
   basic mechanism applies, as long as SBR supports IPv6 and even if it
   is not ILNPv6-capable, as IPv6 ND is used unmodified for ILNPv6.

   For Figure 3.1, assuming:

   - SBR advertises prefix L_1 locally, uses I value I_S, and has an
     Ethernet MAC address M_S on interface with local name sbr0

   - H uses I value I_H, and has an Ethernet MAC address of M_H on the
     interface with local name eth0

   then H will have in its ILCC:

      [I_H, L_1]                                         --- (7a)
      L_1, eth0                                          --- (7b)

   After the IPv6 RA and ND mechanism has executed, the ILCC at H would
   contain, as well as expressions (7a) and (7b), the following entry
   for SBR:

      [I_S, L_1], M_S                                    --- (8)

   For ILNPv6, it does not matter that the SBR is not ILNPv6-capable, as
   the I-LV [I_S, L_1] is physically equivalent to the IPv6 address for
   the internal interface sbr0.

   At SBR, which is not ILNP-capable, there would be the following
   entries in its local cache and configuration:

      L_1:I_S                                           --- (9a)
      L_1, sbr0                                         --- (9b)

   Expression (9a) represents a valid IPv6 ND entry: in this case, the
   I_S value (which is 64 bits in ILNPv6) and the L_1 values are,
   effectively, concatenated and treated as if they were a single IPv6
   address.  Expression (9b) binds transmissions for L_1 to interface
   sbr0.  (Again, sbr0 is a local, implementation-specific name, and
   such a binding is possible with standard tools today, for example,

Top      Up      ToC       Page 23 
4.4.  Packet Routing

   If we assume that host H is configured as in the previous section, it
   is now ready to send and receive ILNP packets.

   Let us assume that, for Figure 4.1, it wishes to contact the node CN,
   which has FQDN and is ILNP-capable.  A DNS query by H
   for will result in NID and L64 records for CN, with
   values I_CN and L_CN, respectively, being returned to H and stored in
   its ILCC:

      [I_CN, L_CN]                                     --- (10)

   This will be considered active as long as the TTL values for the DNS
   records are valid.  If the TTL for an I or L value is zero, then the
   value is still usable but becomes stale as soon as it has been used
   once.  However, it is more likely that the TTL value will be greater
   than zero [BA11] [SBK01].

   Once the CN's I value is known, the upper-layer protocol, e.g., the
   transport protocol, can set up suitable transport-layer session

      <UDP: I_H, I_CN, P_H, P_CN>                     --- (11)

   For routing of ILNP packets, the destination L value in an ILNPv6
   packet header is semantically equivalent to a routing prefix.  So,
   once a packet has been forwarded from a host to its first-hop router,
   only the destination L value needs to be used for getting the packet
   to the destination network.  Once the packet has arrived at the
   router for the site network, local mechanisms and the packet-
   forwarding mechanism, as described above in Section 4.3, allow the
   packet to be delivered to the host.

   For our example of Figure 4.1, H will send a UDP packet over ILNP as:

      <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN>     --- (12a)

   and CN will send UDP packets to H as:

      <UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1>     --- (12b)

   The I value for H used in the transport-layer state (I_H in
   expression (12a)) selects the correct L value (L_1 in this case) from
   the bindings in the ILCC (expression (7a)), and that, in turn,
   selects the correct interface from the ILCC (expression (7b)), as

Top      Up      ToC       Page 24 
   described in Section 4.2.  This gets the packet to the first hop
   router; beyond that, the ILNPv6 packet is treated as if it were an
   IPv6 packet.

5.  Multihoming and Multi-Path Transport

   For multihoming, there are three cases to consider:

      a) Host Multihoming (H-MH): a single host is, individually,
         connected to multiple upstream links, via separate routing
         paths, and those multiple paths are used by that host as it
         wishes.  That is, use of multiple upstream links is managed by
         the single host itself.  For example, the host might have
         multiple valid Locator values on a single interface, with each
         Locator value being associated with a different upstream link

      b) Multi-Path Transport (MTP): This is similar to using ILNP's
         support for host multihoming (i.e., H-MH), so we describe
         multi-path transport here.  (Indeed, for ILNP, this can be
         considered a special case of H-MH.)

      c) Site Multihoming (S-MH): a site network is connected to
         multiple upstream links via separate routing paths, and hosts
         on the site are not necessarily aware of the multiple upstream
         paths.  That is, the multiple upstream paths are managed,
         typically, through a site border router, or via the providers.

   Essentially, for ILNP, multihoming is implemented by enabling:

      a) multiple Locator values to be used simultaneously by a node

      b) dynamic, simultaneous binding between one (or more) Identifier
         value(s) and multiple Locator values

   With respect to the requirements for hosts [RFC1122], the multihoming
   function provided by ILNP is very flexible.  It is not useful to
   discuss ILNP multihoming strictly within the confines of the
   exposition presented in Section 3.3.4 of [RFC1122], as that text is
   couched in terms of relationships between IP Addresses and
   interfaces, which can be dynamic in ILNP.  The closest relationship
   between ILNP multihoming and [RFC1122] would be that certainly ILNP
   could support the notion of "Multiple Logical Networks", "Multiple
   Logical Hosts", and "Simple Multihoming".

Top      Up      ToC       Page 25 
5.1.  Host Multihoming (H-MH)

   At present, host multihoming is not common in the deployed Internet.
   When TCP or UDP are in use with an IP-based network-layer session,
   host multihoming cannot provide session resilience, because the
   transport protocol's pseudo-header checksum binds the transport-layer
   session to a single IP Address of the multihomed node, and hence to a
   single interface of that node.  SCTP has a protocol-specific
   mechanism to support node multihoming; SCTP can support session
   resilience both at present and also without change in the proposed
   approach [RFC5061].

   Host multihoming in ILNP is supported directly in each host by ILNP.
   The simplest explanation of H-MH for ILNP is that an ILNP-capable
   host can simultaneously use multiple Locator values, for example, by
   having a binding between an I value and two different L values, e.g.,
   the ILCC may contain the I-LVs:

      [I_1, L_1]                                       --- (14a)
      [I_1, L_2]                                       --- (14b)

   Additionally, a host may use several I values concurrently, e.g., the
   ILCC may contain the I-LVs:

      [I_1, L_1]                                       --- (15a)
      [I_1, L_2]                                       --- (15b)
      [I_2, L_2]                                       --- (15c)
      [I_3, L_1]                                       --- (15d)

   Architecturally, ILNP considers these all to be cases of multihoming:
   the host is connected to more than one subnetwork, each subnetwork
   being named by a different Locator value.

   In the cases above, the selection of which I-LV to use would be
   through local policy or through management mechanisms.  Additionally,
   suitably modified transport-layer protocols, such as multi-path
   transport-layer protocol implementations, may make use of multiple
   I-LVs.  Note that in such a case, the way in which multiple I-LVs are
   used would be under the control of the higher-layer protocol.

   Recall, however, that L values also have preference -- LPI values --
   and these LPI values can be used at the network layer, or by a
   transport-layer protocol implementation, in order make use of L
   values in a specific manner.

   Note that, from a practical perspective, ILNP dynamically binds L
   values to interfaces on a node to indicate the SNPA for that L value,
   so the multihoming is very flexible: a node could have a single

Top      Up      ToC       Page 26 
   interface and have multiple L values bound to that interface.  For
   example, for expressions (14a) and (14b), if the end-system has a
   single interface with local name eth0, then the entries in the ILCC
   will be:

      L_1, eth0                                       --- (16a)
      L_2, eth0                                       --- (16b)

   And, if we assume that for expressions (15a-c) the end-system has two
   interfaces, eth0 and eth1, then these ILCC entries are possible:

      L_1, eth0                                       --- (17a)
      L_2, eth1                                       --- (17b)

      Let us consider the network in Figure 5.1.

            site                         . . . .
           network                      .       .
           . . . .      +------+ L_1   .         .
          .       .     |      +------.           .
         .         .    |      |      .           .
         .         .----+ SBR  |      . Internet  .
         .         .    |      |      .           .
          .  H    .     |      +------.           .
           . . . .      +------+ L_2   .         .
                                        .       .
                                         . . . .

            L_1 = global Locator value 1
            L_2 = global Locator value 2
            SBR = Site Border Router

        Figure 5.1: A Simple Multihoming Scenario for ILNP

   We assume that H has a single interface, eth0.  SBR will advertise
   L_1 and L_2 internally to the site.  Host H will configure these as
   both reachable via its single interface, eth0, by using ILCC entries
   as in expressions (16a) and (16b).  When packets from H that are to
   egress the site network reach SBR, it can make appropriate decisions
   on which link to use based on the source Locator value (which has
   been inserted by H) or based on other local policy.

   If, however, H has two interfaces, eth0 and eth1, then it can use
   ILCC entries as in expressions (17a) and (17b).

   Note that the values L_1 and L_2 do not need to be PI-based Locator
   values, and can be taken from ISP-specific PA routing prefix
   allocations from the upstream ISPs providing the two links.

Top      Up      ToC       Page 27 
   Of course, this example is illustrative: many other configurations
   are also possible, but the fundamental mechanism remains the same, as
   described above.

   If any Locator values change, then H will discover this when it sees
   new Locator values in RAs from SBR, and sees that L values that were
   previously used are no longer advertised.  When this happens, H will:

      a) maintain existing active network-layer sessions: based on its
         current ILCC entries and active sessions, send Locator Update
         (LU) messages to CNs to notify them of the change of L values.
         (LU messages are synonymous to Mobile IPv6 Binding Updates.)

      b) if required, update its relevant DNS entries with the new L
         value in the appropriate DNS records, to enable correct
         resolution for new incoming session requests.

   From an engineering viewpoint, H also updates its ILCC data, removing
   the old L value(s) and replacing with new L value(s) as required.

   Depending on the nature of the physical change in connectivity that
   the L value change represents, this may disrupt upper-level
   protocols, e.g., a fibre cut.  Dealing with such physical-level
   disruption is beyond the scope of ILNP.  However, ILNP supports
   graceful changes in L values, and this is explained below in Section
   6 in the discussion on mobility support.

5.2.  Support for Multi-Path Transport Protocols

   ILNP supports deployment and use of multi-path transport protocols,
   such as the Multi-Path extensions to TCP (MP-TCP) being defined by
   the IETF TCPM Working Group.  Specifically, ILNP will support the use
   of multiple paths as it allows a single I value to be bound to
   multiple L values -- see Section 5.1, specifically expressions (15a)
   and (15b).

   Of course, there will be specific mechanisms for:
   - congestion control
   - signalling for connection/session management
   - path discovery and path management
   - engineering and implementation issues

   These transport-layer mechanisms fall outside the scope of ILNP and
   would be defined in the multi-path transport protocol specifications.

   As far as the ILNP architecture is concerned, the transport protocol
   connection is simply using multiple I-LVs, but with the same I value
   in each, and different L values, i.e., a multihomed host.

Top      Up      ToC       Page 28 
5.3.  Site Multihoming (S-MH)

   At present, site multihoming is common in the deployed Internet.
   This is primarily achieved by advertising the site's routing
   prefix(es) to more than one upstream Internet service provider at a
   given time.  In turn, this requires de-aggregation of routing
   prefixes within the inter-domain routing system.  This increases the
   entropy of the inter-domain routing system (e.g., RIB/FIB size
   increases beyond the minimal RIB/FIB size that would be required to
   reach all sites).

   Site multihoming, in its simplest form in ILNP, is an extension of
   the H-MH scenario described in Section 5.1.  If we consider Figure
   5.1, and assume that there are many hosts in the site network, then
   each host can choose (a) whether or not to manage its own ILNP
   connectivity, and (b) whether or not to use multiple Locator values.
   This allows maximal control of connectivity for each host.

   Of course, with ILNPv6, just as any IPv6 router is required to
   generate IPv6 Router Advertisement messages with the correct routing
   prefix information for the link the RA is advertised upon, the SBR is
   also required to generate RAs containing the correct Locator value(s)
   for the link that the RA is advertised upon.  The correct values for
   these RA messages are typically configured by system administration,
   or might be passed down from the upstream provider.

   To avoid a DNS Update burst when a site or (sub)network changes
   location, a DNS record optimisation is possible by using the new LP
   record for ILNP.  This would change the number of DNS Updates
   required from Order(Number of nodes within the site/subnetwork that
   moved) to Order(1) [RFC6742].

5.3.1.  A Common Multihoming Scenario - Multiple SBRs

   The scenario of Figure 5.1 is an example to illustrate the
   architectural operation of multihoming for ILNP.  For site
   multihoming, a scenario such as the one depicted in Figure 5.2 is
   also common.  Here, there are two SBRs, each with its own global

Top      Up      ToC       Page 29 
         site                          . . . .
        network                       .       .
        . . . .      +-------+ L_1   .         .
       .       .     |       +------.           .
      .         .    |       |      .           .
     .           .---+ SBR_A |      .           .
     .           .   |       |      .           .
     .           .   |       |      .           .
     .           .   +-------+      .           .
     .           .       ^          .           .
     .           .       | CP       . Internet  .
     .           .       v          .           .
     .           .   +-------+ L_2  .           .
     .           .   |       +------.           .
     .           .   |       |      .           .
     .           .---+ SBR_B |      .           .
      .         .    |       |      .           .
       .       .     |       |      .           .
        . . . .      +-------+       .         .
                                      .       .
                                       . . . .

         CP     = coordination protocol
         L_1    = global Locator value 1
         L_2    = global Locator value 2
         SBR_A  = Site Border Router A
         SBR_B  = Site Border Router B

     Figure 5.2: A Dual-Router Multihoming Scenario for ILNP

   The use of two physical routers provides an extra level of resilience
   compared to the scenario of Figure 5.1.  The coordination protocol
   (CP) between the two routers keeps their actions in synchronisation
   according to whatever management policy is in place for the site
   network.  Such capabilities are available today in products.  Note
   that, logically, there is little difference between Figures 5.1 and
   5.2, but with two distinct routers in Figure 5.2, the interaction
   using CP is required.  Of course, it is also possible to have
   multiple interfaces in each router and more than two routers.

5.4.  Multihoming Requirements for Site Border Routers

   For multihoming, the SBR does NOT need to be ILNP-capable for host
   multihoming or site multihoming.  This is true provided the
   multihoming is left to individual hosts as described above.  In this
   deployment approach, the SBR need only issue Routing Advertisements

Top      Up      ToC       Page 30 
   (RAs) that are correct with respect to its upstream connectivity;
   that is, the SBR properly advertises routing prefixes (Locator
   values) to the ILNP hosts.

   In such a scenario, when hosts in the site network see new Locator
   values, and see that a previous Locator value is no longer being
   advertised, those hosts can update their ILCCs, send Locator Updates
   to CNs, and change connectivity as required.

6.  Mobility

   ILNP supports mobility directly, rather than relying upon special-
   purpose mobility extensions as is the case with both IPv4 [RFC2002]
   (which was obsoleted by [RFC5944]) and IPv6 [RFC6275].

   There are two different mobility cases to consider:

      a) Host Mobility: individual hosts may be mobile, moving across
         administrative boundaries or topological boundaries within an
         IP-based network, or across the Internet.  Such hosts would
         need to independently manage their own mobility.

      b) Network (Site) Mobility: a whole site, i.e., one or more IP
         subnetworks may be mobile, moving across administrative
         boundaries or topological boundaries within an IP-based
         network, or across the Internet.  The site as a whole needs to
         maintain consistency in connectivity.

         Essentially, for ILNP, mobility is implemented by enabling:

      a) Locator values to be changed dynamically by a node, including
         for active network-layer sessions.

      b) use of Locator Updates to allow active network-layer sessions
         to be maintained.

      c) for those hosts that expect incoming network-layer or
         transport-layer session requests (e.g., servers), updates to
         the relevant DNS entries for those hosts.

   It is possible that a device is both a mobile host and part of a
   mobile network, e.g., a smartphone in a mobile site network.  This is
   supported in ILNP as the mechanism for mobile hosts and mobile
   networks are very similar and work in harmony.

Top      Up      ToC       Page 31 
   For mobility, there are two general features that must be supported:

      a) Handover (or Hand-off): when a host changes its connectivity
         (e.g., it has a new SNPA as it moves to a new ILNP subnetwork),
         any active network-layer sessions for that host must be
         maintained with minimal disruption (i.e., transparently) to the
         upper-layer protocols.

      b) Rendezvous: when a host that expects incoming network-layer or
         transport-layer session requests has new connectivity (e.g., it
         has a new SNPA as it moves to a new ILNP subnetwork), it needs
         to update its relevant DNS entries so that name resolution will
         provide the correct I and L values to remote nodes.

6.1.  Mobility / Multihoming Duality in ILNP

   Mobility and multihoming present the same set of issues for ILNP.
   Indeed, mobility and multihoming form a duality: the set of Locators
   associated with a node or site changes.  The reason for the change
   might be different for the case of mobility and multihoming, but the
   effects on the network-layer session state and on correspondents is

   With ILNP, mobility and multihoming are supported using a common set
   of mechanisms.  In both cases, different Locator values are used to
   identify different IP subnetworks.  Also, ILNP nodes that expect
   incoming network-layer or transport-layer session requests are
   assumed to have a Fully Qualified Domain Name (FQDN) stored in the
   Domain Name System (DNS), as is already done within the deployed
   Internet.  ILNP mobility normally relies upon the Secure Dynamic DNS
   Update standard for mobile nodes to update their location information
   in the DNS.  This approach of using DNS for rendezvous with mobile
   systems was proposed earlier by others [PHG02].

   Host Mobility considers individual hosts that are individually mobile
   -- for example, a mobile telephone carried by a person walking in a
   city.  Network (Site) Mobility considers a group of hosts within a
   local topology that move jointly and periodically change their
   uplinks to the rest of the Internet -- for example, a ship that has
   wired connections internally but one or more wireless uplinks to the
   rest of the Internet.

   For ILNP, Host Mobility is analogous to host multihoming (H-MH) and
   Network Mobility is analogous to site multihoming (S-MH).  So,
   mobility and multihoming capabilities can be used together, without

Top      Up      ToC       Page 32 
6.2.  Host Mobility

   With Host Mobility, each individual end-system manages its own
   connectivity through the use of Locator values.  (This is very
   similar to the situation described for H-MH in Section 5.1.)

   Let us consider the network in Figure 6.1.

         site                          . . . .
        network A                     .       .
        . . . .      +-------+ L_A   .         .
       .       .     |       +------.           .
      .         .    |       |      .           .
     .           .---+ SBR_A |      .           .
     .           .   |       |      .           .
     .  H(1)     .   |       |      .           .
     .           .   +-------+      .           .
      . . . . . .                   .           .
       .  H(2) .                    . Internet  .
      . . . . . .                   .           .
     .           .   +-------+ L_B  .           .
     .  H(3)     .   |       +------.           .
     .           .   |       |      .           .
     .           .---+ SBR_B |      .           .
      .         .    |       |      .           .
       .       .     |       |      .           .
        . . . .      +-------+       .         .
         site                         .       .
        network B                      . . . .

         H(X) = host H at position X
         L_A  = global Locator value A
         L_B  = global Locator value B
         SBR  = Site Border Router

     Figure 6.1: A Simple Mobile Host Scenario for ILNP

   A host H is at position (1), hence H(1) in a site network A.  This
   site network might be, for example, a single radio cell under
   administrative domain A.  We assume that the host will move into site
   network B, which might be a single radio cell under administrative
   domain B.  We also assume that the site networks have a region of
   overlap so that connectivity can be maintained; else, of course, the
   host will lose connectivity.  Also, let us assume that the host
   already has ILNP connectivity in site network A.

Top      Up      ToC       Page 33 
   If site network A has connectivity via Locator value L_A, and H uses
   Identifier value I_H with a single interface ra0, then the host's
   ILCC will contain:

      [I_H, L_A]                                           --- (18a)
      L_A, ra0                                             --- (18b)

   Note the equivalence of expressions (18a) and (18b), respectively,
   with the expressions (15a) and (16a) for host multihoming.

   The host now moves into the overlap region of site networks A and B,
   and has position (2), hence H(2) as indicated in Figure 6.1.  As this
   region is now in site network B, as well as site network A, H should
   see RAs from SBR_B for L_B, as well as the RAs for L_A from SBR_A.
   The host can now start to use L_B for its connectivity.  The host H
   must now:

      a) maintain existing active upper-layer sessions: based on its
         current ILCC entries and active sessions, send Locator Update
         (LU) messages to CNs to notify them of the change of L values.
         (LU messages are synonymous to Mobile IPv6 Binding Updates.)

      b) if required, update its relevant DNS entries with the new L
         value in the appropriate DNS records, to enable correct
         resolution for new incoming network-layer or transport-layer
         session requests.

         However, it can opt to do this one of two ways:

      1) immediate handover: the host sends Locator Update (LU) messages
         to CNs, immediately stops using L_A, and switches to using L_B
         only.  In this case, its ILCC entries change to:

         [I_H, L_B]                                        --- (19a)
         L_B, ra0                                          --- (19b)

         There might be packets in flight to H that use L_A, and H MAY
         choose to ignore these on reception.

      2) soft handover: the host sends Locator Update (LU) messages to
         CNS, but it uses both L_A and L_B until (i) it no longer
         receives incoming packets with destination Locator values set
         to L_A within a given time period and (ii) it no longer sees
         RAs for L_A (i.e., it has left the overlap region and so has
         left site network A).  In this case, its ILCC entries change

Top      Up      ToC       Page 34 
         [I_H, L_A]                                        --- (20a)
         L_A, ra0                                          --- (20b)
         [I_H, L_B]                                        --- (20c)
         L_B, ra0                                          --- (20d)

   ILNP does not mandate the use of one handover option over another.
   Indeed, a host may implement both and decide, through local policy or
   other mechanisms (e.g., under the control of a particular transport
   protocol implementation), to use one or other for a specific
   transport-layer session, as required.

   Note that if using soft handover, when in the overlap region, the
   host is multihomed.  Also, soft handover is likely to provide a less
   disruptive handover (e.g., lower packet loss) compared to immediate
   handover, all other things being equal.

   There is a case where both the host and its correspondent node are
   mobile.  In the unlikely event of simultaneous motion that changes
   both nodes' Locators within a very small time period, there is the
   possibility that communication may be lost.  If the communication
   between the nodes was direct (i.e., one node initiated communication
   with another, through a DNS lookup), a node can use the DNS to
   discover the new Locator value(s) for the other node.  If the
   communication was through some sort of middlebox providing a relay
   service, then communication is more likely to disrupted only if the
   middlebox is also mobile.

   It is also possible that high packet loss results in Locator Updates
   being lost, which could disrupt handover.  However, this is an
   engineering issue and does not impact the basic concept of operation;
   additional discussion on this issue is provided in [RFC6741].

   Of course, for any handover, the new end-to-end path through SBR_B
   might have very different end-to-end path characteristics (e.g.,
   different end-to-end delay, packet loss, throughput).  Also, the
   physical connectivity on interface ra0 as well as through SBR_B's
   uplink may be different.  Such impacts on end-to-end packet transfer
   are outside the scope of ILNP.

6.3.  Network Mobility

   For network mobility, a whole site may be mobile, e.g., the SBRs of
   Figure 6.1 have a radio uplink on a moving vehicle.  Within the site,
   individual hosts may or may not be mobile.

   In the simplest case, ILNP deals with mobile networks in the same way
   as for site multihoming: the management of mobility is delegated to
   each host in the site, so it needs to be ILNP-capable.  Each host,

Top      Up      ToC       Page 35 
   effectively, behaves as if it were a mobile host, even though it may
   not actually be mobile.  Indeed, in this way, the mechanism is very
   similar to that for site multihoming.  Let us consider the mobile
   network in Figure 6.2.

         site                        ISP_1
        network        SBR           . . .
        . . . .      +------+ L_1   .     .
       .       .     |   ra1+------.       .
      .         .----+      |      .       .
       .  H    .     |   ra2+--    .       .
        . . . .      +------+       .     .
                                     . . .
      Figure 6.2a: ILNP Mobile Network before Handover

         site                        ISP_1
        network        SBR           . . .
        . . . .      +------+ L_1   .     .
       .       .     |   ra1+------. . . . .
      .         .----+      |      .       .
       .  H    .     |   ra2+------.       .
        . . . .      +------+ L_2  . . . . .
                                    .     .
                                     . . .
       Figure 6.2b: ILNP Mobile Network during Handover

         site                        ISP_2
        network        SBR           . . .
        . . . .      +------+       .     .
       .       .     |   ra1+--    .       .
      .         .----+      |      .       .
       .  H    .     |   ra2+------.       .
        . . . .      +------+       .     .
                                     . . .
       Figure 6.2c: ILNP Mobile Network after Handover

           H = host
         L_1 = global Locator value 1
         L_2 = global Locator value 2
         SBR = Site Border Router

     Figure 6.2: A Simple Mobile Network Scenario for ILNP

Top      Up      ToC       Page 36 
   In Figure 6.2, we assume that the site network is mobile, and the SBR
   has two radio interfaces ra1 and ra2.  However, this particular
   figure is chosen for simplicity and clarity for our scenario, and
   other configurations are possible, e.g., a single radio interface
   which uses separate radio channels (separate carriers, coding
   channels, etc.).  In the figure, ISP_1 and ISP_2 are separate, radio-
   based service providers, accessible via ra1 and ra2.

   In Figure 6.2a, the SBR has connectivity via ISP_1 using Locator
   value L_1.  The host H, with interface ra0 and Identifier I_H, has an
   established connectivity via the SBR and so has ILCC entries as shown
   in (21):

      [I_H, L_1]                                           --- (21a)
      L_1, ra0                                             --- (21b)

   Note the equivalence to expressions (18a) and (18b).  As the whole
   network moves, the SBR detects a new radio provider, ISP_2, and
   connects to it using ra2, as shown in Figure 6.2b, with the service
   areas of ISP_1 and ISP_2 overlapping.  ISP_2 provides Locator L_2,
   which the SBR advertises into the site network along with L_1.  As
   with the mobile host scenario above, individual hosts may decide to
   perform immediate handover or soft handover.  So, the ILCC state for
   H will be as for expressions (19a) and (19b) and (20a)-(20d), but
   with L_1 in place of L_A, and L_2 in place of L_B.  Finally, as in
   Figure 6.2c, the site network moves and is no longer served by ISP_1,
   and handover is complete.  Note that during the handover the site is
   multihomed, as in Figure 6.2b.

6.4.  Mobility Requirements for Site Border Routers

   As for multihoming, the SBR does NOT need to be ILNP-capable: it
   simply needs to advertise the available routing prefixes into the
   site network.  The mobility capability is handled completely by the

6.5.  Mobility with Multiple SBRs

   Just as Section 5.3.1 describes the use of multiple routers for
   multihoming, so it is possible to have multiple routers for mobility
   for ILNP, for both mobile hosts and mobile networks.

(page 36 continued on part 3)

Next RFC Part