[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 6748

Internet Draft                                               RJ Atkinson
draft-irtf-rrg-ilnp-adv-00.txt                                Consultant
Expires:  12 Jul 2012                                          SN Bhatti
Category: Experimental                                     U. St Andrews
                                                         January 12 2012

            Optional Advanced Deployment Scenarios for ILNP

Status of this Memo

   Distribution of this memo is unlimited.

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s)
   controlling the copyright in such materials, this document may not
   be modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards Process,
   except to format it for publication as an RFC or to translate it
   into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other

Atkinson & Bhatti  Expires in 6 months                          [Page 1]

Internet Draft     ILNP ADV           12 Jan 2012

   documents at any time. It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is not on the IETF standards-track and does not
   specify any level of standard. This document merely provides
   information for the Internet community.


   This document provides an Architectural description and the
   Concept of Operations of some optional advanced deployment
   scenarios for the Identifier-Locator Network Protocol (ILNP),
   which is an evolutionary enhancement to IP. None of the functions
   described here is required for the use or deployment of ILNP.
   Instead, it offers descriptions of engineering and deployment
   options that might provide either enhanced functionality or
   convenience in administration or management of ILNP-based systems.

Table of Contents

     1. Introduction......................................1
     2. Localised Addressing..............................2
     3. An Alternative For Site Multi-Homing..............3
     4. An Alternative For Site (Network) Mobility........4
     5. Traffic Engineering Options.......................5
     6. Location Privacy..................................6
     7. Identity Privacy..................................7
     8. Security Considerations...........................8
     9. IANA Considerations...............................9
    10. References........................................10


   ILNP is, in essence, an end-to-end architecture: the functionality
   required for ILNP is implemented in, and controlled from, only
   those end-systems that wish to use ILNP, as described in
   [ILNP-ARCH]. Other nodes, such as Site Border Routers (SBRs) need
   only support IP to allow operation of ILNP, e.g. an SBR should
   support IPv6 in order to enable end-systems to operate ILNPv6

Atkinson & Bhatti  Expires in 6 months                          [Page 2]

Internet Draft     ILNP ADV           12 Jan 2012

   within the site network for which SBR provides a service

   However, some features of ILNP could be optimised, from an
   engineering perspective, by the use of an intermediate system (a
   router, security gateway or "middlebox") that modifies (rewrites)
   Locator values of transit ILNP packets. It would also perform
   other control functions for an entire site, as an administrative
   convenience, such as providing a centralised point of management
   for a site. For example, an SBR might manipulate the topological
   presence of the packet, providing an elegant solution to the
   provision of functionality such as site (network) mobility for an
   entire end site [ABH09a].

   This document discusses several such optional advanced deployment
   scenarios for ILNP. These typically use an ILNP-capable Site
   Border Router (SBR).

   Nothing in this document is a requirement for any ILNP
   implementation or any ILNP deployment.

   Readers are strongly advised to first read the ILNP Architecture
   Description [ILNP-ARCH], as this document uses the notation and
   terminology described or referenced in that document.

1.1 Document roadmap

   This document describes optional engineering and deployment
   functions for the Identifier Locator Network Protocol (ILNP). The
   authors recommend reading and understanding [ILNP-ARCH] as the
   starting point to understanding ILNP.

   The term ILNPv6 refers precisely to an instance of ILNP that is
   based upon, and backwards compatible with, IPv6. The term ILNPv4
   refers precisely to an instance of ILNP that is based upon, and
   backwards compatible with, IPv4.

   Many engineering aspects common to both ILNPv4 and ILNPv6 are
   described in [ILNP-ENG]. A full engineering specification for
   either ILNPv6 or ILNPv4 is beyond the scope of this document.

   Readers are referred to other related ILNP documents for details
   not described here:

    a) [ILNP-ARCH] is the main architectural description of ILNP,
       including the concept of operations.

    b) [ILNP-ENG] describes engineering and implementation

Atkinson & Bhatti  Expires in 6 months                          [Page 3]

Internet Draft     ILNP ADV           12 Jan 2012

       considerations that are common to both ILNPv4 and ILNPv6.

    c) [ILNP-DNS] defines additional DNS resource records that
       support ILNP.

    d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message
       used by an ILNP node to inform its correspondent nodes
       of any changes to its set of valid Locators.

    e) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option
       used by ILNPv6 nodes (1) to indicate to ILNP correspondent
       nodes (by inclusion within the initial packets of an ILNP
       session) that the node is operating in the ILNP mode and
       (2) to prevent off-path attacks against ILNP ICMP messages.
       This Nonce is used, for example, with all ILNP ICMPv6
       Locator Update messages that are exchanged among ILNP
       correspondent nodes.

    f) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message
       used by an ILNP node to inform its correspondent nodes
       of any changes to its set of valid Locators.

    g) [ILNP-v4opts] defines a new IPv4 Nonce Option used by ILNPv4
       nodes to carry a security nonce to prevent off-path attacks
       against ILNP ICMP messages and also defines a new IPv4
       Identifier Option used by ILNPv4 nodes.

1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   in this document are to be interpreted as described in RFC 2119


   Today, Network Address Translation [RFC3022] is used for a number
   of purposes. Whilst one of the original intentions of NAT was to
   reduce the rate of use of global IPv4 addresses, NAT also offers
   to site administrators a convenient localised address management
   capability coupled with a local/private address space, e.g.
   [RFC1918] for IPv4. So, while for IPv6, NAT would not necessarily
   be required to reduce the rate of IPv6 address depletion (as the
   availability of addresses is not such an issue as for IPv4),
   localised management in a similar manner to IPv4 NAT is still
   desirable for IPv6 [RFC5902], even though there is debate about
   the efficacy of such an approach [RFC4864].

Atkinson & Bhatti  Expires in 6 months                          [Page 4]

Internet Draft     ILNP ADV           12 Jan 2012

   One of the major concerns that many have had with NAT is the loss
   of end-to-end session state invariance which is still considered
   an important architectural principle by the IAB [RFC4924].

   However, it is possible to have the benefits of NAT-like
   functionality for ILNP without losing end-to-end state. Indeed,
   such a mechanism - the use of Locator re-writing in ILNP - forms
   the basis of much of the optional functionality described in this
   document. In ILNP, we call this feature "localised numbering".

   Recall, that a Locator value in ILNP has the same semantics as a
   routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [ILNP-ENG],
   routing prefixes from IPv4 and IPv6, respectively, are used as
   Locator values.

   We note that a deployment using private/local numbering can also
   provide a convenient solution to centralised management of site
   multi-homing and network mobility by deploying SBRs in this manner
   - this is described below.

   Please note that with this proposal, localised numbering (e.g.
   using the equivalent of IP NAT on the ILNP Locator bits) would
   work in harmony with multihoming, mobility (for individual hosts
   and whole networks), and IP Security, plus the other advanced
   functions described in this document [BA11] [LABH06] [ABH07a]
   [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10]
   [ABH10] [BAK11].

2.1 Localised numbering

   For ILNP, the NAT-like function can best be descried by using a
   simple example, based on Figure 2.1.

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

            CN = Correspondent Node
             H = Host

Atkinson & Bhatti  Expires in 6 months                          [Page 5]

Internet Draft     ILNP ADV           12 Jan 2012

           L_1 = global Locator value
           L_L = local Locator value
          SBR = Site Border Router

        Figure 2.1: A simple localised numbering example for ILNP.

   In this scenario, the SBR is allocated global locator value L_1
   from the upstream provider. However, the SBR advertises internally
   a "local" Locator value L_L. By "local" we mean that the Locator
   value only has significance within the site network, and any
   packets that have L_L as a source Locator cannot be forwarded
   beyond the SBR with value L_L as the source Locator. In
   engineering terms, L_L would, for example in ILNPv6, be an IPv6
   prefix based on the assignments possible according to IPv6 Unique
   Local Addresses (ULA) [RFC4193].

   We assume that H uses Identifier I_H then it will use
   Identifier-Locator Vector (IL-V) <I_H, L_L>, and that the
   correspondent node (CN) uses IL-V <I_CN, L_CN>. If we consider
   that H will send a UDP packet from its port P_H to CN's port P_CN,
   then, H could send a UDP/ILNP packet with the tuple expression:

     <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN>           --- (1a)

   When this packet reaches the SBR, it knows that L_L is a local
   Locator value and so re-writes the source Locator on the egress
   packet to L_1, and forwards that out onto its external-facing
   interface. The value L_1 is a global prefix, which allows the
   packet to be routed globally:

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

   This packet reaches CN using normal routing based on the Locator
   value L_1, as it is a routing prefix.

   Note that from expressions (1a) and (1b), the end-to-end state (in
   the UDP tuple) remains unchanged - end-to-end state invariance is
   honoured, for UDP. CN would send a UDP packet to H as:

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

   and the SBR would re-write the Locator value on the ingress packet
   before forwarding the packet on its internal interface:

     <UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L>           --- (2b)

   Again, this preserves the end-to-end session state invariance.

Atkinson & Bhatti  Expires in 6 months                          [Page 6]

Internet Draft     ILNP ADV           12 Jan 2012

   As the Locator values are not used in the transport layer pseudo
   header for ILNP [ILNP-ENG], the checksum would not have to be
   re-written. That is, the Locator re-writing function is stateless
   and has low overhead.

   (A discussion on the generation of Identifier values for initial
   use is presented in [ILNP-ENG].)

2.2 Mixed local/global numbering

   It is possible for the SBR to advertise both L_1 and L_L within
   the site, and for hosts within the site to have IL-Vs using both
   L_1 and L_L. For example, host H may have IL-Vs <I_H, L_1> and
   <I_H, L_L>. The configuration and use of such a mechanism can be
   controlled through local policy.

2.3 Localised name resolution with DNS

   To support private numbering with IPv4 and IPv6 today, some sites
   use a split-horizon DNS service for the site [ID-appDNS].

   If a site using localised numbering chooses to deploy a
   split-horizon DNS server, then the DNS server would return the
   global-scope Locator(s) (L_1 in our example above) of the SBR to
   DNS clients outside the site, and would advertise the local-scope
   Locator(s) (L_L in our example above) specific to that internal
   node to DNS clients inside the site. Such deployments of
   split-horizon DNS servers are not unusual in the IPv4 Internet
   today. If an internal node (e.g. portable computer) moves outside
   the site, it would follow the normal ILNP methods to update its
   authoritative DNS server with its current Locator set. In this
   deployment model, the authoritative DNS server for that mobile
   device will be either the split-horizon DNS server itself or the
   master DNS server providing data to the split-horizon DNS server.

   If a site using localised numbering chooses not to deploy a
   split-horizon DNS server, then all internal nodes would advertise
   the global-scope Locator(s) of the site border routers. To deliver
   packets from one internal node to another internal node, the site
   would either choose to use layer-2 bridging (e.g. IEEE Spanning
   Tree or IEEE Rapid Spanning Tree [IEEE04], or a link-state layer-2
   algorithm such as the IETF TRILL group or IEEE 802.1 are
   developing), or the interior routers would forward packets up to
   the nearest site border router, which in turn would then rewrite
   the Locators to appropriate local-scope values, and forward the
   packet towards the interior destination node.

Atkinson & Bhatti  Expires in 6 months                          [Page 7]

Internet Draft     ILNP ADV           12 Jan 2012

   Alternately, for sites using localised numbering but not deploying
   a split-horizon DNS server, the DNS server could return all
   global-scope and local-scope Locators to all queriers, and to
   assume that nodes would use normal, local address/route selection
   criteria to choose the best Locator to use to reach a given remote
   node [RFC3484]. Hosts within the same site as the correspondent
   node would only have a ULA configured, and hence would select the
   ULA destination Locator for the correspondent (L_L in our
   example). Hosts outside the site would not have the same ULA
   configured (L_CN for the CN in our example). Note that RFC3484
   probably needs to be updated to indicate that the longest-prefix
   matching rule is inadequate when comparing ULA-based Locators with
   global-scope Locators: to choose a ULA for a correspondent, a node
   must have a Locator that matches all ULA bits of the target
   Locator value.

2.4 Use of mDNS

   Multicast DNS (mDNS) [ID-mDNS11] is popularly used in many
   end-system OSs today, especially desktop OSs (such as Windows,
   MacOSX and Linux). It is used for localised name resolution using
   names with a ".local" suffix, for both IPv4 and IPv6. This
   protocol would need to be modified so that when an ILNP-capable
   node advertises its ".local" name, another ILNP-capable node would
   be able to see that it is an ILNP-capable, but other, non-ILNP
   nodes would not be perturbed in operation. The details of a
   mechanism for enabling such functionality in mDNS has not yet been

2.5 Site network name in DNS

   In this scenario, if H expects incoming session requests, for
   example, remote nodes may need to look up appropriate
   Identifier-Locator information in the DNS. Just as for IP, and as
   already described in [ILNP-ARCH], a Fully Qualified Domain Name
   (FQDN) lookup for H should resolve to the correct ID and L32/L64
   records. If there are many hosts like H that need to keep DNS
   records (for any reason, including to allow incoming session
   requests), then, potentially, there are many such RRs. As an
   optimisation, the network as a whole may be configured with a L32
   and L64 records (to store the value L_1 from our example) that are
   resolved from an FQDN. At the same time, individual hosts now have
   an FQDN that returns one or more LP record entries [ILNP-DNS] as
   well as ID records. The LP record points to the L32 or L64 records
   for the site.

Atkinson & Bhatti  Expires in 6 months                          [Page 8]

Internet Draft     ILNP ADV           12 Jan 2012

2.6  Site Interior Topology Obfuscation

   In some situations, it can be desirable to obfuscate the details
   of the interior topology of an end site. Alternately, in some
   situations, local site policy requires that local-scope routing
   prefixes be used within the local site. ILNP can provide these
   capabilities through the ILNP local functionality described here,
   under the control of the SBR.

2.7 Other SBR considerations

   In the near-term, a more common deployment scenario will be to
   deploy ILNP incrementally, with some ordinary classic IP traffic
   still existing. In this case, the SBR should maintain flow state
   that contains a flag for each flow indicating whether that flow is
   using ILNP or not. If that flag indicated ILNP were enabled for a
   given flow, and ILNP local numbering were also enabled, then the
   SBR would know that it should perform the simpler ILNP Locator
   re-writing mapping. If that flag indicated ILNP were not enabled
   for a given flow and IP NAT or IP NAPT were also enabled, then the
   SBR would know that it should perform the more complex NAT/NAPT
   translation (e.g. including TCP or UDP checksum recalculation).

       NOTE: Existing commercial security-aware routers
       (e.g. Juniper SRX routers) already can maintain flow state
       for millions of concurrent IP flows.  This feature would add
       one flag to each flow's state, so this approach is believed
       scalable today using existing commercial technology.

   Those applications that do not use IP address values in
   application state or configuration data are considered to be
   "well-behaved". For well-behaved applications, no further
   enhancements are required. Where application-layer protocols are
   not well-behaved, for example the File Transfer Protocol (FTP),
   then the SBR might need to perform additional stateful processing
   -- just as NAT and NAPT equipment needs to do today for FTP. Se
   the describtion in Section 7.6 of [ILNP-ENG].

   When the SBR rewrites a Locator in an ILNP packet, that obscures
   information about how well a particular path is working between
   the sender and the receiver of that ILNP packet. So, the SBR that
   rewrites Locator values needs to include mechanisms to ensure that
   any packet with a new Destination Locator will travel along a
   valid path to the intended destination node. For ILNPv4, the path
   liveness will be no worse than IPv4, and mechanisms already in use
   for IPv4 can be re-used. For ILNPv6, the path liveness will be no
   worse than for IPv6, and mechanisms already in use for IPv6 can be

Atkinson & Bhatti  Expires in 6 months                          [Page 9]

Internet Draft     ILNP ADV           12 Jan 2012


   In future, the Border Router Discovery Protocol (BRDP) also might
   be used in some deployments to indicate which routing prefixes are
   currently valid and which site border routers currently have a
   working uplink [ID-BRDP11].


   The ILNP Architectural Description [ILNP-ARCH] describes the basic
   approach to enabling site multi-homing (S-MH) with ILNP. However,
   as an option, it is possible to leave the control of S-MH to an
   ILNP-enabled SBR. This alternative is based on the use of the
   Localised Numbering function described in Section 2 of this

3.1 Site multi-homing (S-MH) connectivity using an SBR

   The functionality for S-MH using an SBR is best illustrated
   through an example, as shown in Figure 3.1.

          site                         . . . .      +----+
         network         SBR          .       .-----+ CN |
         . . . .      +------+ L_1   .         .    +----+
        .       .     |  sbr1+------.           .
       .         .L_L |      |      .           .
       .         .----+      |      . Internet  .
       .  H      .    |      |      .           .
        .       .     |  sbr2+------.           .
         . . . .      +------+ L_2   .         .
                                     .       .
                                      . . . .

             CN = Correspondent Node
              H = Host
            L_1 = global Locator value 1
            L_2 = global Locator value 2
            L_L = local Locator value
            SBR = Site Border Router
           sbrN = interface N on SBR

      Figure 3.1: Alternative site multi-homing example with an SBR.

   The situation here is similar to the localised numbering example,
   except that the SBR now has two external links, with using locator
   value L_1 and another using Locator value L_2. These could, e.g.
   for ILNPv6, be separate, provider aggregated (PA) IPv6 prefixes

Atkinson & Bhatti  Expires in 6 months                         [Page 10]

Internet Draft     ILNP ADV           12 Jan 2012

   from two different ISPs. H has IL-V <I_H, L_L>, and will forward a
   packet to CN as given in expression (1a). However, when the packet
   reaches the SBR, local policy will decide whether the packet is
   forwarded on the link sbr1 using L_1 or on sbr2 using L_2. Of
   course, the correct Locator value will be re-written into the
   egress packet in place of L_L.

   If only local numbering is being used, then the SBR need never
   advertise any global Locator values. However, it could do, as
   described in Section 2.2.

3.2 Dealing with link/connectivity changes

   One of the key uses for multi-homing if resilience to link
   failure. If either link breaks, then the SBR can manage the change
   in connectivity locally. For example, assume SBR has been
   configured to use sbr1 for all traffic, and sbr2 only as backup
   link. So, SBR directs packets from H to communicate with CN using
   sbr1, and CN will receive packets as in expression (1b) and
   respond with packets as in expression (2a).

   However, if sbr1 goes down then SBR will move the communication
   to interface sbr2. As H is not aware of the actions of the SBR,
   the SBR must maintain some state about IL-V "pairs" in order
   hand-off the connectivity from sbr1 to sbr2. So, when moving the
   the communication to sbr2, the SBR would firstly send a Locator
   Update (LU) message [ILNP-ICMPv4] [ILNP-ICMPv6], to CN informing
   it that L_2 is now the valid Locator for the communication. This
   operation would not be visible to H, although there ay be some
   disruption to transmission, e.g. packets being sent from CN to H
   that are in flight when sbr1 goes down may be lost. The SBR may
   also need to update DNS entries (see Section 3.3).

   This approach has some efficiency gains over the approach for
   multi-homing described in [ILNP-ARCH], where each hosts manages
   its own connectivity.

   If sbr1 was to be re-instated, now with Locator value L_3, then
   local policy would determine if the communication should be moved
   back to sbr1, with appropriate additional actions, such as
   transmission of LU messages with the new Locator values and also
   the updates to DNS.

   Note that in such movement of session across interfaces at the
   SBR, only Locator values in ILNP packets are changed. As already
   noted in [ILNP-ARCH], end-to-end session state invariance is

Atkinson & Bhatti  Expires in 6 months                         [Page 11]

Internet Draft     ILNP ADV           12 Jan 2012

3.3 SBR updates to DNS

   When the SBR manages connectivity as described above, the internal
   hosts, such as H, are not necessarily aware of any connectivity
   changes. Indeed, there is certainly no requirement for them to be
   aware. So, if H was a server expecting incoming connections, the
   SBR must update the relevant DNS entries when the site
   connectivity changes.

   There are two possibilities: each record could have its own L32
   or L64 records; or the site might use a combination of LP and
   L32/L64 records (see Section 2.4). Either way, the SBR would need
   to update the relevant DNS entries. For our example, with ILNPv6
   and LP records in use, the SBR would need to manage two L64
   records (one for each interface) which would resolve from a FQDN,
   for example, site.example.com. Meanwhile, individual hosts, such
   as H, have an FQDN which resolves to an ID value and an LP record
   that would contain the value site.example.com, which would then be
   used to lookup the two L64 records.

3.4 DNS TTL values for L32 and L64 records

   Imagine that in the scenario described above, there was a link
   failure that resulted in sbr1 going down and sbr2 was used.
   Existing sessions in progress would move to sbr2 as described
   above. However, new incoming sessions to the site would need to
   know to use L_2 and not L_1. L_1 and L_2 would be stored in DNS
   records (e.g. L32 for ILNPv4 or L64 for ILNPv6). A remote hosts
   that has already resolved from DNS that L_1 is the correct to send
   packets to the site, then it may be holding stale information.

   DNS allows values returned to be aged using Time-To-Live (TTL)
   which is specified in the time unit of seconds. So that remote
   nodes do not hold on to stale values from DNS, the L64 records for
   our site should have low TTL values. An appropriate value must be
   considered carefully. For example, let us assume that the site
   administrator knows that when sbr1 fails, it takes 20 seconds to
   failover to sbr2. Then, 20s would seem to be an appropriate time
   to use for the TTL value of an L64 for the site: if a remote node
   had just resolved the value L_1 for the site, and the link to sbr1
   went down, that remote node would not hold the stale value of L_1
   for any longer than it takes the site to failover to sbr2 and use

   Our studies for a university School site network show that low TTL
   values, as low as zero, are feasible for operational use [BA11].

Atkinson & Bhatti  Expires in 6 months                         [Page 12]

Internet Draft     ILNP ADV           12 Jan 2012

   NOTE: From 01 Nov 2010, the site network of the School of Computer
         Science, University of St Andrews, UK, has been running
         operational DNS with DNS A records that have TTL of zero.
         At the time of writing of this note (05 Jan 2011),
         a zero DNS TTL was still in use at the school.


   The ILNP Architectural Description [ILNP-ARCH] describes the basic
   approach to enabling site (network) mobility with ILNP. However,
   as an option, it is possible to leave the control of site mobility
   to an ILNP-enabled SBR by exploiting the alternative site
   multi-homing feature described in Section 3 of this document.

   Again, as described in [ILNP-ARCH], we exploit the duality between
   mobility and multi-homing for ILNP.

4.1 Site (network) mobility

   Let us consider the mobile network in Figure 4.2, which is taken
   from [ILNP-ARCH].

          site                        ISP_1
         network        SBR           . . .
         . . . .      +------+ L_1   .     .
        .       . L_L |   ra1+------.       .
       .         .----+      |      .       .
        .  H    .     |   ra2+--    .       .
         . . . .      +------+       .     .
                                      . . .

       Figure 4.1a: ILNP mobile network before handover.

          site                        ISP_1
         network        SBR           . . .
         . . . .      +------+ L_1   .     .
        .       . L_L |   ra1+------. . . . .
       .         .----+      |      .       .
        .  H    .     |   ra2+------.       .
         . . . .      +------+ L_2  . . . . .
                                     .     .
                                      . . .

       Figure 4.1b: ILNP mobile network during handover.

          site                        ISP_2
         network        SBR           . . .

Atkinson & Bhatti  Expires in 6 months                         [Page 13]

Internet Draft     ILNP ADV           12 Jan 2012

         . . . .      +------+       .     .
        .       . L_L |   ra1+--    .       .
       .         .----+      |      .       .
        .  H    .     |   ra2+------.       .
         . . . .      +------+ L_2   .     .
                                      . . .

       Figure 4.1c: ILNP mobile network after handover.

            H = host
          L_1 = global Locator value 1
          L_2 = global Locator value 2
          L_L = local Locator value
          raN = radio interface N
          SBR = Site Border Router

     Figure 4.1: An alternative mobile network scenario with an SBR.

   We assume that the site (network) is mobile, and the SBR has two
   radio interfaces ra1 and ra2. In the figure, ISP_1 and ISP_2 are
   separate, radio-based service providers, accessible via interfaces
   ra1 and ra2.

   While the SBR makes the transition from using a single link (Fig.
   4.1a) to the hand-over overlap on both links (Fig 4.1b), to only
   using a single link again (Fig 4.1c), the host H continues to use
   only Locator value L_L, as already described for site multi-homing
   (S-MH). During this time the actions taken by the SBR are the same
   as already described in [ILNP-ARCH], except that the SBR:

      a) also performs that ILNP localised numbering function
         described in Section 2.
      b) does not need to advertise L_1 and L_2 internally if only
         local numbering is being used.

   As for the case of S-MH above, H need not be aware of the change
   in connectivity for the SBR if it is only using local numbering,
   and the SBR would send LU messages for H (for any correspondent
   nodes, not shown in Fig 4.1), and would update DNS entries as

   The difference to the S-MH scenario described earlier in this
   document is that in the situation of Fig 4.1b, the SBR can opt to
   use soft handover has previously described in [ILNP-ARCH].

   Again, there is an efficiency gain compared to the situation
   described in [ILNP-ARCH]: the SBR provides a convenient point at
   which to centrally manage the movement of the site as a whole.

Atkinson & Bhatti  Expires in 6 months                         [Page 14]

Internet Draft     ILNP ADV           12 Jan 2012

   Note that in Fig 4.1b, the site is multi-homed.

   As for S-MH, L_1 and L_2 could be advertised internally, as a
   local policy decision, for those hosts that require direct control
   of their connectivity.

   Note that for handover, immediate handover will have a similar
   behaviour to a link outage as described for S-MH. However, as ILNP
   allows soft-handover, during the handover period, this should help
   to reduce (perhaps even remove) packet loss.

4.3 SBR updates to DNS

   As for S-MH, a similar discussion to Section 3.3 applies for
   mobile networks with respect to the updates to DNS. As a mobile
   network is likely to have more frequent changes to its
   connectivity than a multi-homed network would due to connectivity
   changes, the use of LP DNS records is likely to be particularly
   advantageous here.

4.4 DNS TTL values for L32 and L64 records

   As for S-MH, a similar discussion to Section 3.4 applies for
   mobile networks with respect to the TTL of L32 and/or L64 records
   that are used for the name of the mobile network. In the case of
   the mobile network, it makes sense for the TTL to be aligned to
   the time for handover.


   The use of Locator re-writing provides some simple yet useful
   options for traffic engineering (TE) controlled from the edge-site
   via the SBR, requiring no cooperation from the service provider
   other than the provision of basic connectivity services, e.g.
   physical connectivity, allocation of IP address prefixes and
   packet forwarding. This does not preclude other TE options that
   are already in use, such as use of MPLS, but we choose to
   highlight here the specific options available and controllable
   solely through the use of ILNP.

   When a site network is multi-homed, we have seen that the use of
   the Locator re-writing function permits the SBR to have
   packet-by-packet control when forwarding on external links.
   Various configuration and policies could be applied at the SBR in
   order to control the egress and ingress traffic to the site

Atkinson & Bhatti  Expires in 6 months                         [Page 15]

Internet Draft     ILNP ADV           12 Jan 2012

5.1 Load balancing

   Let us consider Figure 6.1, and assume ILNP local numbering is in
   use; that H1, H2 and H3 use, respectively, Identifier values, I_1,
   I_2 and I_3; and all of them use Locator value L_L.

           site                         . . . .
          network         SBR          .       .
          . . . .      +------+ L_1   .         .
         .       .     |  sbr1+------.           .
        .     H2  .L_L |      |      .           .
        . H3      .----+      |      . Internet  .
        .         .    |      |      .           .
         .  H1   .     |  sbr2+------.           .
          . . . .      +------+ L_2   .         .
                                       .       .
                                        . . . .

            HN = host N
           L_1 = global Locator value 1
           L_2 = global Locator value 2
           L_L = local Locator value
           SBR = Site Border Router
          sbrN = interface N on sbr

      Figure 6.1: A site multi-homing scenario for traffic control.

   The SBR could be configured, subject to local policy, to try to
   control load across the external links. For example, it could be
   configured initially with the following mappings:

     srcI=I_1, sbr1                                        --- (3a)
     srcI=I_2, sbr2                                        --- (3b)
     srcI=I_3, sbr1                                        --- (3c)

   These mappings direct packets matching course Identifier values to
   particular outgoing interfaces. As load changes, these mappings
   could be changed. For example, expression (3c) could be changed

     srcI=I_3, sbr2                                        --- (4)

   and the SBR would need to send LU message to the correspondents of
   H3 (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity
   is totally within control of the SBR under administrative policy,
   as already seen in the descriptions of multi-homing and mobility
   in this document.

Atkinson & Bhatti  Expires in 6 months                         [Page 16]

Internet Draft     ILNP ADV           12 Jan 2012

   Of course, more complex policies are possible, based on:

    - whether sessions are incoming or outgoing
    - time of day
    - internal subnets

   and any number of criteria already in use for control of traffic.

   In expressions (3a,b,c) above, source I values are used. However:

    - destination I values could be used
    - source or destination L values could be used
    - mappings could be to L values, not to specific interfaces

   and, again, any number of criteria to manipulate the packet path
   based on filtering of values in header fields and local policy.

   With ILNP, hosts do not need to be aware of the operation of the
   SBR in this manner.

   Note, again, that in this scenario, there is nothing to prevent
   SBR from also advertising L_1 and L_2 into the site network. If
   required, administrative controls could be used to enable
   selective hosts in the site network to use L_1 and L_2 directly as
   describe din [ILNP-ARCH].

5.2 Control of egress traffic paths

   Extending the scenario for load-balancing described above, it is
   also be possible for the ILNP-capable SBR to direct traffic along
   specific network paths based on the use of different L values,
   i.e. by using multiple prefixes assigned from upstream providers.
   Of course, as previously discussed, these prefixes can be Provider
   Aggregated (PA) and need not be Provider Independent (PI).

   Let us consider Figure 6.2, and assume ILNP local numbering is in
   use; that H1, H2 and H3 use, respectively, Identifier values, I_1,
   I_2 and I_3; and all of them use Locator value L_L. Let us also
   assume that the node CN uses IL-V <I_CN, L_CN>.

           site                           . . . .      +----+
          network         SBR            .       .-----+ CN |
          . . . .      +------+ L1,L2   .         .    +----+
         .       .     |  sbr1+--------.           .
        .     H2  .L_L |      |        .           .
        . H3      .----+  sbr2+--------. Internet  .
        .         .    |      | L3,L4  .           .
        .         .    |      |        .           .

Atkinson & Bhatti  Expires in 6 months                         [Page 17]

Internet Draft     ILNP ADV           12 Jan 2012

         .  H1   .     |  sbr3+--------.           .
          . . . .      +------+ L5,L6   .         .
                                         .       .
                                          . . . .

            CN = correspondent node
            HN = host N
            LN = global Locator value N
           L_L = local Locator value
           SBR = Site Border Router
          sbrN = interface N on sbr

      Figure 6.2: A site multi-homing scenario for traffic control.

   Here, many configurations are possible. For example, for egress

     srcI=I_2, L2                                          --- (5a)
     srcI=I_3, L3                                          --- (5b)
     dstI=I_CN, L6                                         --- (5c)
     srcI=I_1 dstI=I_CN, L1                                --- (5d)

   Expression (5a) maps all egress packets from H2 to have their
   source Locator value re-written to L2 (and implicitly to use
   interface sbr1). Expression (5b) maps all egress packets from H3
   to have their source Locator value re-written to L3 (and
   implicitly to use interface sbr2). Expression (5c) directs ay
   traffic to CN to use Locator value L6 as the source Locator (and
   implicitly to use interface sbr3), and may override (5a) and (5b),
   subject to local policy, when packets to CN are from H2 or H3.

   Meanwhile, in expression (5d), we see a further, more specific
   rule, in that packets from H1 destined to CN should use Locator
   value L1 (and implicitly to use interface sbr1).

   Note the implicit bindings to interfaces in expressions
   (5a,b,c,d), compared to the explicit bindings in expressions
   (3a,b,c). ILNP only requires that the Locator values are correctly
   re-written and packets forwarded in conformance with the routing
   already configured for the Locator values.

   Of course, these rules can be changed dynamically at the SBR, and
   the SBR will migrate sessions across Locator values, as already
   described above for mobility.


Atkinson & Bhatti  Expires in 6 months                         [Page 18]

Internet Draft     ILNP ADV           12 Jan 2012

   Extending the Locator re-writing paradigm, it is possible to also
   enable Location privacy for ILNP by a modified version of the
   "onion routing" paradigm that is used for Tor [DMS04].

6.1 Locator Re-writing Relay (LRR)

   To enable this function, we use a middlebox which we call the the
   Locator Re-writing Relay. The function of this unit is described
   by the use of Figure 7.1.

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

           |     |   src=<I_H, L_1>, L_X                   --- (6b)
           | LRR |   dst=<I_H, L_X>, L_1                   --- (6c)
           |     |

      <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN>         --- (6d)

   The operation of the LRR is conceptually very simple. We assume
   that the LRR first has mappings as given in expressions (6b) and
   (6c) (see next sub-section). Expression (6b) says that for packets
   with src IL-V <I_H, L_1>, the packet's source Locator value should
   be re-written to value L_X and then forwarded. Expression (6c) has
   the complimentary mapping for packets with destination IL-V <I_H,
   L_1> (for the reverse direction).

   Expression (6a) is a UDP/ILNP packet as might be sent in Figure
   2.1 from H to CN. However, instead of going directly to L_CN, the
   packet with destination Locator L_1 goes to a LRR. Expression (6d)
   is the result of the mapping of packet (6a) using expression (6b).

   Note that it is entirely possible that the packet of expression
   (6d) then is processed by another LRR for source Locator value
   L_X. Effectively, this creates and LRR path for the packet, as an
   overlay path on top of the normal IP routing.

   In this way, there is a level of protection, without the need for
   cryptographic techniques, for the (topological) Location of the
   packet. Of course, an extremely well-resourced adversary could,
   potentially, backtrack the LRR path, but, depending on the LRR
   overlay path that is created, could be very difficult to trace in
   reality. For example, the mechanism will protect against off-path

Atkinson & Bhatti  Expires in 6 months                         [Page 19]

Internet Draft     ILNP ADV           12 Jan 2012

   attacks, but where the threat regime includes the potential for
   on-path attacks, cryptographically protected tunnels between H and
   LRR might be required.

   Again, as the Locator value is not part of the end-to-end state,
   this mechanism is very general and has a low overhead.

   6.1 Options for installing LRR packet forwarding state

   There are many options for managing the "network" of LRRs that
   could be in place if such a system was used on a large scale,
   including the setting up and removal of LRR state for packet
   relaying, as for expressions (6b) and (6c). We consider this
   functionality to be outside the scope ILNP, but there are many
   existing mechanisms that could modified for use, and many
   possibilities for new mechanisms specific to the use of ILNP LRRs.

   (Note also that the control/management communication with the LRR
   does not need to use ILNP: IPv4 or IPv6 could be used.)

   The host, H, could itself could install the required state,
   assuming it was aware of suitable information to contact the LRR.
   The first packet in a session might contain a header option called
   a Locator Redirection Option (LRO). The LRO would contain the
   Locator value that should be re-written into the source Locator of
   the packet. When a LRR receives such a packet, it would install
   the required state. Such a mechanism could be soft-state,
   requiring periodic use of the LRO in order to maintain the state
   in the LRR. The LRO could also be delivered using an ICMP ECHO
   packet sent from H to the LRR, periodically, again to maintain a
   soft-state update.

   It would, of course, be prudent to protect the LRR state control
   packets with some sort of authentication token, to prevent and
   adversary easily installing false LRR state and causing packets
   from H or its correspondent to be subject to man-in-the-middle
   attacks, or black-holing. Again, such attacks are not specific to

   It would also be possible to use proprietary application level
   protocols, with strong authentication for the control of the LRR
   state. For example, an application level protocol based on XMPP
   (http://xmpp.org/) operating over SSL.

   Above, we have offered very brief and incomplete descriptions of
   some possibilities, and we do not necessarily mandate any one of
   them: they serve only as examples.

Atkinson & Bhatti  Expires in 6 months                         [Page 20]

Internet Draft     ILNP ADV           12 Jan 2012


   For the sake of completeness, and in complement to Section 6, it
   should be noted that ILNP can use either cryptographically
   verifiable Identifier values, or use Identifier values that
   provide a level of anonymity to protect a user's privacy. More
   details are given in Section 2 of [ILNP-ENG].


   The relevant security considerations to this document are the same
   as for the main ILNP Architectural Description [ILNP-ARCH]. The
   one additional point to note is that this document descries ILNP
   capability in the SBR and so those adversaries wishing to subvert
   the operation of ILNP specifically, have a target that would,
   potentially, disable an entire site. However, this is not an
   attack vector that is specific to ILNP: today, disruption of an
   IPv4 or IPv6 SBR would the same impact.

   The security considerations for Section 7 (Location Privacy) are
   already documented in [DMS04]. One possibility is that the LRR
   mechanism itself could be used by an adversary to launch an attack
   and hide his own (topological) Location, for example. This is
   already possible for IPv4 and IPv4 with a Tor-like system today,
   so is not new to ILNP.

9.  IANA Considerations

       There are no IANA considerations for this document.
       (Note to RFC Editor: please remove this section
        prior to publication.)


10.1.  Normative References

   [ILNP-ARCH]  R. Atkinson & S. Bhatti,
                "ILNP Architectural Description",
                draft-irtf-rrg-ilnp-arch, Jan 2012.

   [ILNP-ENG]   R. Atkinson & S. Bhatti,
                "ILNP Engineering and Implementation Considerations",
                draft-irtf-rrg-ilnp-eng, Jan 2012.

   [ILNP-DNS]   R. Atkinson, S. Bhatti, & S Rose,
                "DNS Resource Records for ILNP",

Atkinson & Bhatti  Expires in 6 months                         [Page 21]

Internet Draft     ILNP ADV           12 Jan 2012

                draft-irtf-rrg-ilnp-dns, Jan 2012.

   [ILNP-ICMPv4]  R. Atkinson & S. Bhatti,
                  "ICMPv4 Locator Update message"
                  draft-irtf-rrg-ilnp-icmpv4, Jan 2012.

   [ILNP-ICMPv6]  R. Atkinson & S. Bhatti,
                  "ICMPv6 Locator Update message"
                  draft-irtf-rrg-ilnp-icmpv6, Jan 2012.

   [ILNP-NONCEv6] R. Atkinson & S. Bhatti,
                 "IPv6 Nonce Destination Option for ILNPv6",
                 draft-irtf-rrg-ilnp-noncev6, Jan 2012.

   [ILNP-v4opts] R. Atkinson & S. Bhatti, "IPv4 Options for ILNP",
                 draft-irtf-rrg-ilnp-v4opts, Jan 2012.

   [RFC1918]     Y. Rekther, B. Moskowitz, D. Karrenberg & G. J.
                 de Groot,
                 "Address Allocation for Private Internets",
                 RFC1918, Feb 1996

   [RFC2119]     S. Bradner, "Key Words for Use in RFCs to
                 Indicate Requirement Levels", RFC-2119,
                 March 1997.

   [RFC3022]     P. Srisuresh & K. Egevang,
                 "Traditional IP Network Address Translator
                 (Traditional NAT)",
                 RFC3022, Jan 2011.

   [RFC3484]     R. Draves,
                 "Default Address Selection for IPv6",
                 RFC3484, Feb 2003.

   [RFC4864]     G. Van de Velde, T. Hain, R. Droms, B. Carpenter &
                 E. Klein,
                 "Local Network Protection for IPv6",
                 RFC4864, May 2007

   [RFC4924]     B. Adoba & E. Davbies (eds),
                 "Reflections on Internet Transparency",
                 RFC4924, Jul 2007

   [RFC5902]     D. Thaler, L. Zhang & G. Lebovitz,
                 "IAB Thoughts on IPv6 Network Address Translation",
                 RFC5902, Jul 2010

Atkinson & Bhatti  Expires in 6 months                         [Page 22]

Internet Draft     ILNP ADV           12 Jan 2012

10.2.  Informative References

   [ABH07a]    R. Atkinson, S. Bhatti, & S. Hailes,
               "Mobility as an Integrated Service Through the Use of
               Naming", Proc. ACM MobiArch2007, Kyoto, Japan.
               Aug 2007.

   [ABH07b]    R. Atkinson, S. Bhatti, & S. Hailes,
               "A Proposal for Unifying Mobility with Multi-Homing,
               NAT, & Security", Proc. of ACM MobiWAC 2007, Chania,
               Crete. Oct 2007.

   [ABH08a]    R. Atkinson, S. Bhatti, & S. Hailes,
               "Mobility Through Naming: Impact on DNS", Proc. ACM
               MobiArch 2008, Seattle, WA, USA. Aug 2008.

   [ABH08b]    R. Atkinson, S. Bhatti, & S. Hailes,
               "Harmonised Resilience, Security, and Mobility
               Capability for IP", Proc. MILCOM2008 - 27th IEEE
               Military Communications Conference, San Diego, CA,
               USA. Nov 2008.

   [ABH09a]    R. Atkinson, S. Bhatti, & S. Hailes,
               "Site-Controlled Secure Multi-Homing and Traffic
               Engineering For IP", Proc. MILCOM2009 - 28th IEEE
               Military Communications Conference, Boston, MA, USA.
               Oct 2009.

   [ABH09b]    R. Atkinson, S. Bhatti, S. Hailes,
               "ILNP: Mobility, Multi-Homing, Localised Addressing and
               Security Through Naming"", Telecommunication Systems,
               vol. 42, no. 3-4, pp273-291, Springer-Verlag, Dec 2009.

   [ABH10]     R. Atkinson, S. Bhatti, S. Hailes,
               "Evolving the Internet Architecture Through Naming",
               IEEE Journal on Selected Areas in Communication
               (JSAC), vol. 28, no. 8, pp1319-1325, IEEE, Oct 2010.

   [BA11]      S. Bhatti & R. Atkinson,
               "Reducing DNS Caching", Proc. GI2011 - 14th IEEE
               Global Internet Symposium, Shanghai, China.
               15 Apr 2011.

   [BAK11]     S. N. Bhatti, R. Atkinson, J. Klemets,
               "Integrating Challenged Networks", Proc. MILCOM2011 -
               30th IEEE Military Communications Conference,
               Baltimore, USA. 09-12 Nov 2011.

Atkinson & Bhatti  Expires in 6 months                         [Page 23]

Internet Draft     ILNP ADV           12 Jan 2012

   [DMS04]     R. Dingledine, N. Mathewson, & P. Syverson,
               "Tor: the second-generation onion router", Proc. 13th
               USENIX Security Symposium, San Diego, CA, USA. 2004.

   [ID-appDNS] O. Kolman, J. Peterson, H. Tschofenig & B. Aboba,
               "Architectural Considerations on Application Features
               in the DNS",
               draft-iab-dns-applications-03, 31 Oct 2011.

   [ID-BRDP11] T. Boot & A. Holtzer,
               "BRDP Framework",
               draft-boot-brdp-framework-00, 31 Jan 2011.

   [ID-mDNS11] S. Cheshire, M. Krochmal,
               "Multicast DNS",
               draft-cheshire-dnsext-multicastdns-15, 09 Dec 2011.

   [IEEE04]    "IEEE 802.1D - IEEE Standard for Local and Metropolitan
               Area Networks, Media Access Control (MAC) Bridges",
               IEEE, New York, NY, USA, 9 June 2004.
               Print: ISBN 0-7381-3881-5 SH95213
               PDF: ISBN 0-7381-3982-3 SS95213

   [LABH06]    R. Atkinson, M. Lad, S. Bhatti, and S. Hailes,
               "A Proposal for Coalition Networking in Dynamic
               Operational Environments", Proc. MILCOM2006 - 25th
               IEEE Military Communications Conference, Washington DC,
               USA. Nov 2006.

   [RAB09]     D. Rehunthan, R. Atkinson, S. Bhatti,
               "Enabling Mobile Networks Through Secure Naming",
               Proc. MILCOM2009 - 28th IEEE Military Communications
               Conference (MILCOM), Boston, MA, USA, Oct 2009

   [RB10]      D. Rehunathan, S. Bhatti,
               "A Comparative Assessment of Routing for Mobile
               Networks", Proc. WiMob2010 - 6th IEEE International
               Conference on Wireless and Mobile Computing,
               Networking and Communications, Niagara Falls, Canada.
               11-13 Oct 2010.

   [RFC4193]   R. Hinden and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC-4193, October 2005.


   Steve Blake, Mohamed Boucadair, Noel Chiappa, Steve Hailes, Joel
   Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim,

Atkinson & Bhatti  Expires in 6 months                         [Page 24]

Internet Draft     ILNP ADV           12 Jan 2012

   Tony Li, Yakov Rehkter, Robin Whittle and John Wroclawski (in
   alphabetical order) provided review and feedback on earlier
   versions of this document. Steve Blake provided an especially
   thorough review of an early version of the entire ILNP document
   set, which was extremely helpful. We also wish to thank the
   anonymous reviewers of the various ILNP papers for their feedback.

Author's Address

   RJ Atkinson
   San Jose, CA
   95125 USA

   Email:     rja.lists@gmail.com

   SN Bhatti
   School of Computer Science
   University of St Andrews
   North Haugh, St Andrews
   Fife, Scotland
   KY16 9SX, UK

   Email: saleem@cs.st-andrews.ac.uk

   Expires: 12 Jul 2012

Atkinson & Bhatti  Expires in 6 months                         [Page 25]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/