doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc6748.txt b/doc/rfc/rfc6748.txt
new file mode 100644
index 0000000..181546c
--- /dev/null
+++ b/doc/rfc/rfc6748.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                          RJ Atkinson
+Request for Comments: 6748                                    Consultant
+Category: Experimental                                         SN Bhatti
+ISSN: 2070-1721                                            U. St Andrews
+                                                           November 2012
+
+
+             Optional Advanced Deployment Scenarios for the
+               Identifier-Locator Network Protocol (ILNP)
+
+Abstract
+
+   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 capability or convenience in administration or management of
+   ILNP-based systems.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Research Task
+   Force (IRTF).  The IRTF publishes the results of Internet-related
+   research and development activities.  These results might not be
+   suitable for deployment.  This RFC represents the individual
+   opinion(s) of one or more members of the Routing Research Group of
+   the Internet Research Task Force (IRTF).  Documents approved for
+   publication by the IRSG are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6748.
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 1]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+Copyright Notice
+
+   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.
+
+   This document may not be modified, and derivative works of it may not
+   be created, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 2]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Document Roadmap ...........................................5
+      1.2. Terminology ................................................6
+   2. Localised Numbering .............................................6
+      2.1. Localised Locators .........................................7
+      2.2. Mixed Local/Global Numbering ...............................9
+      2.3. Dealing with Internal Subnets with Locator Rewriting .......9
+      2.4. Localised Name Resolution with DNS ........................11
+      2.5. Use of mDNS ...............................................13
+      2.6. Site Network Name in DNS ..................................13
+      2.7. Site Interior Topology Obfuscation ........................14
+      2.8. Other SBR Considerations ..................................14
+   3. An Alternative for Site Multihoming ............................16
+      3.1. Site Multihoming (S-MH) Connectivity Using an SBR .........16
+      3.2. Dealing with Link/Connectivity Changes ....................17
+      3.3. SBR Updates to DNS ........................................18
+      3.4. DNS TTL Values for L32 and L64 Records ....................18
+      3.5. Multiple SBRs .............................................19
+   4. An Alternative for Site (Network) Mobility .....................20
+      4.1. Site (Network) Mobility ...................................20
+      4.2. SBR Updates to DNS ........................................22
+      4.3. DNS TTL Values for L32 and L64 Records ....................22
+   5. Traffic Engineering Options ....................................22
+      5.1. Load Balancing ............................................23
+      5.2. Control of Egress Traffic Paths ...........................24
+   6. ILNP in Datacentres ............................................26
+      6.1. Virtual Image Mobility within a Single Datacentre .........27
+      6.2. Virtual Image Mobility between Datacentres - Invisible ....28
+      6.3. Virtual Image Mobility between Datacentres - Visible ......29
+      6.4. ILNP Capability in the Remote Host for VM Image Mobility ..29
+   7. Location Privacy ...............................................30
+      7.1. Locator Rewriting Relay (LRR) .............................30
+      7.2. Options for Installing LRR Packet Forwarding State ........31
+   8. Identity Privacy ...............................................32
+   9. Security Considerations ........................................32
+   10. References ....................................................33
+      10.1. Normative References .....................................33
+      10.2. Informative References ...................................34
+   11. Acknowledgements ..............................................37
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 3]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+1.  Introduction
+
+   This document is part of the ILNP document set, which has had
+   extensive review within the IRTF Routing RG.  ILNP is one of the
+   recommendations made by the RG Chairs.  Separately, various refereed
+   research papers on ILNP have also been published during this decade.
+   So, the ideas contained herein have had much broader review than the
+   IRTF Routing RG.  The views in this document were considered
+   controversial by the Routing RG, but the RG reached a consensus that
+   the document still should be published.  The Routing RG has had
+   remarkably little consensus on anything, so virtually all Routing RG
+   outputs are considered controversial.
+
+   At present, the Internet research and development community is
+   exploring various approaches to evolving the Internet Architecture to
+   solve a variety of issues including, but not limited to, scalability
+   of inter-domain routing [RFC4984].  A wide range of other issues
+   (e.g., site multihoming, node multihoming, site/subnet mobility, node
+   mobility) are also active concerns at present.  Several different
+   classes of evolution are being considered by the Internet research
+   and development community.  One class is often called "Map and
+   Encapsulate", where traffic would be mapped and then tunnelled
+   through the inter-domain core of the Internet.  Another class being
+   considered is sometimes known as "Identifier/Locator Split".  This
+   document relates to a proposal that is in the latter class of
+   evolutionary approaches.
+
+   ILNP is, in essence, an end-to-end architecture: the functions
+   required for ILNP are implemented in, and controlled by, only those
+   end-systems that wish to use ILNP, as described in [RFC6740].  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 within the site network for
+   which an SBR provides a service [RFC6741].
+
+   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 functions such as site (network) mobility for an entire
+   end site [ABH09a].
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 4]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   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 [RFC6740], as this document uses the notation and
+   terminology described or referenced in that document.
+
+1.1.  Document Roadmap
+
+   This document describes engineering and implementation considerations
+   that are common to ILNP for both IPv4 and IPv6.
+
+   The ILNP architecture can have more than one engineering
+   instantiation.  For example, one can imagine a "clean-slate"
+   engineering design based on the ILNP architecture.  In separate
+   documents, we describe two specific engineering instances of 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 [RFC6741].  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) [RFC6740] is the main architectural description of ILNP, including
+      the concept of operations.
+
+   b) [RFC6741] describes engineering and implementation considerations
+      that are common to both ILNPv4 and ILNPv6.
+
+   c) [RFC6742] defines additional DNS resource records that support
+      ILNP.
+
+   d) [RFC6743] 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.
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 5]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   e) [RFC6744] 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) [RFC6745] 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) [RFC6746] 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.
+
+   h) [RFC6747] describes extensions to Address Resolution Protocol
+      (ARP) for use with ILNPv4.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Localised Numbering
+
+   Today, Network Address Translation (NAT) [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, through use of
+   IPv4 private address space [RFC1918], NAT also offers to site
+   administrators a convenient localised address management capability
+   combined with a local-scope/private address space, for example,
+   [RFC1918] for IPv4.
+
+   For IPv6, NAT would not necessarily be required to reduce the rate of
+   IPv6 address depletion, because the availability of addresses is not
+   such an issue as for IPv4.  The IETF has standardised Unique Local
+   IPv6 Unicast Addresses [RFC4193], which provide local-scope IPv6
+   unicast address space that can be used by end sites.  However,
+   localised address management, in a manner similar to that provided by
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 6]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   IPv4 NAT and private address space [RFC1918], is still desirable for
+   IPv6 [RFC5902], even though there is debate about the efficacy of
+   such an approach [RFC4864].
+
+   One of the major concerns that many have had with NAT is the loss of
+   end-to-end transport-layer and network-layer session state
+   invariance, which is still considered an important architectural
+   principle by the IAB [RFC4924].  Nevertheless, the use of localised
+   addressing remains in wide use and there is interest in its continued
+   use in IPv6, e.g., proposals such as [RFC6296].
+
+   It is possible to have the benefits of NAT-like functions for ILNP
+   without losing end-to-end state.  Indeed, such a mechanism -- the use
+   of Locator rewriting in ILNP -- forms the basis of many of the
+   optional functions 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 [RFC6741], 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
+   multihoming 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 (IPsec), plus the other advanced functions
+   described in this document [BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a]
+   [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11].
+
+2.1.  Localised Locators
+
+   For ILNP, the NAT-like function can best be descried by using a
+   simple example, based on Figure 2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 7]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+          site                         . . . .      +----+
+         network        SBR           .       .-----+ CN |
+         . . . .      +------+ L_1   .         .    +----+
+        .       .     |      +------.           .
+       .         .L_L |      |      .           .
+       .         .----+      |      . Internet  .
+       .  H      .    |      |      .           .
+        .       .     |      |      .           .
+         . . . .      +------+       .         .
+                                      .       .
+                                       . . . .
+
+            CN = Correspondent Node
+             H = Host
+           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 (ULAs) [RFC4193].
+
+   If we assume that H uses Identifier I_H, then it will use Identifier-
+   Locator Vector (I-LV) [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 rewrites 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.
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 8]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   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 rewrite 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 transport-layer session state
+   invariance.
+
+   As the Locator values are not used in the transport-layer pseudo-
+   header for ILNP [RFC6741], the checksum would not have to be
+   rewritten.  That is, the Locator rewriting function is stateless and
+   has low overhead.
+
+   (A discussion on the generation of Identifier values for initial use
+   is presented in [RFC6741].)
+
+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.  Dealing with Internal Subnets with Locator Rewriting
+
+   Where the site network uses subnets, packets will need to be routed
+   correctly, internally.  That is, the site network may have several
+   internal Locator values, e.g., L_La, L_Lb, and L_Lc.  When an ingress
+   packet has I-LV [I_H, L_1], it is expected that the SBR is capable of
+   identifying the correct internal network for I_H, and so the correct
+   Locator value to rewrite for the ingress packet.  This is not obvious
+   as the I value and the L value are not related in any way.
+
+   There are numerous ways the SBR could facilitate the correct lookup
+   of the internal Locator value.  This document does not prescribe any
+   specific method.  Of course, we do not preclude mappings directly
+   from Identifier values to internal Locator values.
+
+   Of course, such a "flat" mapping (between Identifier values and
+   Locators) would serve, but maintaining such a mapping would be
+   impractical for a large site.  So, we propose the following solution.
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 9]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Consider that the Locator value, L_x consists of two parts, L_pp and
+   L_ss, where L_pp is a network prefix and L_ss is a subnet selector.
+   Also, consider that this structure is true for both the local
+   identifier, L_L, as well as the global Identifier, L_1.  Then, an SBR
+   need only know the mapping from the values of L_ss as visible in L_1
+   and the values of L_ss used locally.
+
+   Such a mapping could be mechanical, e.g., the L_ss part of L_L and
+   L_1 are the same and it is only the L_pp part that is different.
+   Where this is not desirable (e.g., for obfuscation of interior
+   topology), an administrator would need to configure a suitable
+   mapping policy in the SBR, which could be realised as a simple lookup
+   table.  Note that with such a policy, the L_pp for L_L and L_1 do not
+   need to be of the same size.
+
+   From a practical perspective, this is possible for both ILNPv6
+   [RFC6177] and ILNPv4 [RFC4632].  For ILNPv6, recall that the Locator
+   value is encoded to be syntactically similar to an IPv6 address
+   prefix, as shown in Figure 2.2, taken from [RFC6741].
+
+   /* IPv6 */
+   | 3 |     45 bits         |  16 bits  |     64 bits             |
+   +---+---------------------+-----------+-------------------------+
+   |001|global routing prefix| subnet ID |  Interface Identifier   |
+   +---+---------------------+-----------+-------------------------+
+   /* ILNPv6 */
+   |             64 bits                 |     64 bits             |
+   +---+---------------------+-----------+-------------------------+
+   |          Locator (L64)              |  Node Identifier (NID)  |
+   +---+---------------------+-----------+-------------------------+
+   +<-------- L_pp --------->+<- L_ss -->+
+
+     L_pp = Locator prefix part (assigned IPv6 prefix)
+     L_ss = Locator subnet selector (locally managed subnet ID)
+
+   Figure 2.2: IPv6 Address format [RFC3587] as used in ILNPv6, showing
+   how subnets can be identified.
+
+   Note that the subnet ID forms part of the Locator value.  Note also
+   that [RFC6177] allows the global routing prefix to be more than 45
+   bits, and for the subnet ID to be smaller, but still preserving the
+   64-bit size of the Locator overall.
+
+   For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which
+   is typically less than 32 bits.  However, the ILNPv4 Locator value is
+   carried in the 32-bit IP Address space, so the bits not used for the
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 10]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix,
+   the situation would be as shown in Figure 2.3, and L_ss could use any
+   of the remaining 8-bits as required.
+
+              24 bits           8 bits
+     +------------------------+----------+
+     |         Locator (L32)             |
+     +------------------------+----------+
+     +<------- L_pp --------->+<- L_ss ->+
+
+     L_pp = Locator prefix (assigned IPv4 prefix)
+     L_ss = Locator subnet selector (locally managed subnet ID)
+
+   Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in
+   ILNPv4, showing how subnets can be identified.
+
+   As an example, for the case where the interior topology is not
+   obfuscated, an interior "engineering" node might have an LP record
+   pointing to eng.example.com and eng.example.com might have L32/L64
+   records for a specific subnet inside the site.  Meanwhile, an
+   interior "operations" node might have an LP record pointing at
+   "ops.example.com" that might have different L32/L64 records for that
+   specific subnet within the site.  That is, eng.example.com might have
+   Locator value L_pp_1:L_ss_1 and ops.example.com might have Locator
+   value L_pp_1:L_ss_2.  However, just as for IPv6 or IPv4 routing
+   today, the routing for the site would only need to use L_pp_1, which
+   is a routing prefix in either IPv6 (for ILNPv6) or IPv4 (for ILNPv4).
+
+2.4.  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 [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.
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 11]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   If a site using localised numbering chooses not to deploy a split-
+   horizon DNS server, then each internal node would advertise the
+   global-scope Locator(s) of the site border routers in its respective
+   DNS entries.  To deliver packets from one internal node to another
+   internal node, the site would choose to use either 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.
+
+   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 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] for
+   older IPv6 nodes, [RFC6724] for newer IPv6 nodes).  Hosts within the
+   same site as the correspondent node would only have a ULA configured;
+   hence, they 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).
+
+   However, ILNP allows use of Locator Preference values [RFC6742]
+   [RFC6743].  These values would indicate explicitly the relative
+   preference value given to Locator values and so result in the
+   selection of the appropriate Locator (and therefore interface) to use
+   for the transmission of an outgoing packet with respect to the value
+   to be inserted into the IPv6 Source Address field (see Section 3 of
+   [RFC6741]).  A similar argument, with respect to use of Locator
+   preference values, applies to the value to be inserted into the IPv6
+   Destination Address field.  Certainly, by using appropriate
+   Preference values for a host with multiple Locator values, it would
+   be possible to emulate some level of resemblance to the address
+   selection rules in [RFC3484] and [RFC6724], and this could be
+   controlled via DNS entries for ILNP nodes, for example.
+
+   Indeed, with appropriate use of localised or site-wide policy, and
+   appropriate mechanisms in the devices (e.g. in end hosts operating
+   systems or in Site Border Routers), Preference values for Locator
+   values within the DNS could be used for allowing options for multi-
+   homed transport sessions and/or site-controlled traffic engineering
+   [ABH09a].  However, the details for this are left for further study,
+   and overall, the rules defined in [RFC3484] and [RFC6724] cannot be
+   applied directly to ILNPv6 nodes.
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 12]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Note that for split-horizon operation, there needs to be a DNS
+   management policy for mobile hosts, as when such hosts are away from
+   their "home" network, they will need to update DNS entries so that
+   the global-scope Locator(s) only is (are) used, and these are
+   consistent with the current topological position of the mobile host.
+   Such updates would need to be done using Secure Dynamic DNS Update.
+
+   For an ILNP mobile network using LP records, there are likely to
+   separate LP records for internal and external use.
+
+2.5.  Use of mDNS
+
+   Multicast DNS (mDNS) [mDNS11] is popularly used in many end-system
+   OSs today, especially desktop OSs (such as Windows, Mac OS X 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 using mDNS to enable such
+   a feature are not defined here.
+
+2.6.  Site Network Name in DNS
+
+   In this scenario, if H expects incoming ILNP session requests, for
+   example, then remote nodes normally will need to look up appropriate
+   Identifier and Locator information in the DNS.  Just as for IP, and
+   as already described in [RFC6740], a Fully Qualified Domain Name
+   (FQDN) lookup for H should resolve to the correct NID and L32/L64
+   records.  If there are many hosts like H that need to keep DNS
+   records (for any reason, including to allow incoming ILNP session
+   requests), then, potentially, there are many such DNS resource
+   records.
+
+   As an optimisation, the network as a whole may be configured with one
+   or more 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 [RFC6742]
+   as well as NID records.  The LP record points to the L32 or L64
+   records for the site.  A multihomed site normally will have at least
+   one L32 or L64 record for each distinct uplink (i.e., link from a
+   Site Border Router towards the global Internet), because ILNP uses
+   provider-aggregatable addressing.
+
+   More than one L32 or L64 will be required if multiple Locator values
+   are in use.  For example, if an ILNPv6 site has multiple links for
+   multihoming, it will use one L64 record for each Locator value it is
+   using on each link.
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 13]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+2.7.  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 addressing capability described
+   here, under the control of the SBR.
+
+   As described in Section 2.3 above, locator rewriting can be used to
+   hide the internal structure of the network with respect to the
+   subnetting arrangement of the site network.  Specifically, the
+   procedure described in Section 2.3 would be followed, with the
+   following additional modification of the use of Locator values:
+
+   (1) Only the aggregated Locator value, i.e., L_pp, is advertised
+       outside the site (e.g., in an L32 or L64 record), and L_ss is
+       zeroed in that advertisement.
+
+   (2) The SBR needs to maintain a mapping table to restore the interior
+       topology information for received packets, for example, by using
+       a mapping table from I values to either L_ss values or internal
+       Locator values.
+
+   (3) The SBR needs to zero the L_ss values for all Source Locators of
+       egress packets, as well as perform a Locator rewriting that
+       affects the L_pp bits of the Locator value.
+
+   Of course, this only obscures the interior topology of the site, not
+   the exterior connectivity of the site.  In order for the site to be
+   reachable from the global Internet, the site's DNS entries need to
+   advertise Locator values for the site to the global Internet (e.g.,
+   in L32, L64 records).
+
+2.8.  Other SBR Considerations
+
+   For backwards compatibility, for ILNP, the ICMP checksum is always
+   calculated identically as for IPv6 or IPv4.  For ILNPv6, this means
+   that the SBR need not be aware if ILNPv6 is operating as described in
+   [RFC6740] and [RFC6741].  For ILNPv4, again, the SBR need not be
+   aware of the operation if ILNPv4 is operating as it will not need to
+   inspect the extension header carrying the I value.
+
+   In order to support communication between two internal nodes that
+   happen to be using global-scope addresses (for whatever reason), the
+   SBR MUST support the "hair pinning" behaviour commonly used in
+   existing NAT/NAPT devices.  (This behaviour is described in Section 6
+   of RFC 4787 [RFC4787].)
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 14]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   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 or not that flow is
+   using ILNP.  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 rewriting
+   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.  See the description in Section 7.6 of
+   [RFC6741].
+
+   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 reused.  For ILNPv6, the path liveness will be no worse than
+   for IPv6, and mechanisms already in use for IPv6 can be reused.
+
+   In the 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 [BRDP11].
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 15]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+3.  An Alternative for Site Multihoming
+
+   The ILNP Architectural Description [RFC6740] describes the basic
+   approach to enabling Site Multihoming (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 document.
+
+3.1.  Site Multihoming (S-MH) Connectivity Using an SBR
+
+   The approach to Site Multihoming (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 Multihoming 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 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 rewritten into the egress packet in place of
+   L_L.
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 16]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   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 multihoming is providing 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 to hand off the
+   connectivity from sbr1 to sbr2.  So, when moving the communication to
+   sbr2, the SBR would firstly send a Locator Update (LU) message
+   [RFC6745] [RFC6743], 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 might 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 might also need to update DNS entries (see
+   Section 3.3).  Since ILNP requires that all Locator Update messages
+   be authenticated by the ILNP Nonce, the SBR will need to include the
+   appropriate Nonce values as part of its cache of information about
+   ILNP sessions traversing the SBR.  (NOTE: Since commercial security
+   gateways available as of this writing reportedly can handle full
+   stateful packet inspection for millions of flows at multi-gigabit
+   speeds, it should be practical for such devices to cache the ILNP
+   flow information, including Nonce values.)
+
+   This approach has some efficiency gains over the approach for
+   multihoming described in [RFC6740], where each hosts manages its own
+   connectivity.
+
+   If sbr1 was to be reinstated, 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 an ILNP session across interfaces at
+   the SBR, only Locator values in ILNP packets are changed.  As already
+   noted in [RFC6740], end-to-end transport-layer session state
+   invariance is maintained.
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 17]
+
+RFC 6748                        ILNP ADV                   November 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 host 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 uplink) that would resolve from a FQDN, for example,
+   site.example.com.  Meanwhile, individual hosts, such as H, have an
+   FQDN that resolves to an NID value and an LP record that would
+   contain the value site.example.com, which then would be used to look
+   up the two L64 records.
+
+   If the SBR is multihomed, as in Figure 3.1, then it will have (at
+   least) two Locator values, one for each link, and local policy will
+   need to be used to determine how preference values are applied in the
+   relevant L32 and 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
+   ILNP sessions in progress would move to sbr2 as described above.
+   However, new incoming ILNP 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).  If a remote host has
+   already resolved from DNS that L_1 is the correct Locator for sending
+   packets to the site, then that host might 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, 20 s 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 L_2.
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 18]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Our studies for a university school site network show that low TTL
+   values, as low as zero, are feasible for operational use [BA11].
+
+   NOTE: From 01 November 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 document (November 2012),
+         a zero DNS TTL was still in use at the school.
+
+3.5.  Multiple SBRs
+
+   For site multihoming, with multiple SBRs, a situation may be as
+   follows (see also Section 5.3.1 in [RFC6740]).
+
+         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 P
+
+   Figure 3.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 3.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
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 19]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   network.  Such functions are available today in some commercial
+   network security products.  Note that, logically, there is little
+   difference between Figures 5.1 and 3.2, but with two distinct routers
+   in Figure 3.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.
+
+4.  An Alternative for Site (Network) Mobility
+
+   The ILNP Architectural Description [RFC6740] 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 multihoming
+   feature described in Section 3 of this document.
+
+   Again, as described in [RFC6740], we exploit the duality between
+   mobility and multihoming for ILNP.
+
+4.1.  Site (Network) Mobility
+
+   Let us consider the mobile network in Figure 4.2, which is taken from
+   [RFC6740].
+
+          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  . . . . .
+                                     .     .
+                                      . . .
+                                      ISP_2
+
+       Figure 4.1b: ILNP Mobile Network during Handover
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 20]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+          site                        ISP_2
+         network        SBR           . . .
+         . . . .      +------+       .     .
+        .       . 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 (Figure
+   4.1a) to the handover overlap on both links (Figure 4.1b), to only
+   using a single link again (Figure 4.1c), the host H continues to use
+   only Locator value L_L, as already described for Site Multihoming
+   (S-MH).  During this time the actions taken by the SBR are the same
+   as already described in [RFC6740], 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 Figure 4.1), and would update DNS entries as required.
+
+   The difference to the S-MH scenario described earlier in this
+   document is that in the situation of Figure 4.1b, the SBR can opt to
+   use soft handover has previously described in [RFC6740].
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 21]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Again, there is an efficiency gain compared to the situation
+   described in [RFC6740]: the SBR provides a convenient point at which
+   to centrally manage the movement of the site as a whole.  Note that
+   in Figure 4.1b, the site is multihomed.
+
+   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.2.  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
+   multihomed network would due to connectivity changes, the use of LP
+   DNS records is likely to be particularly advantageous here.
+
+4.3.  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.
+
+5.  Traffic Engineering Options
+
+   The use of Locator rewriting 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 multihomed, we have seen that the use of the
+   Locator rewriting 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 network.
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 22]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+5.1.  Load Balancing
+
+   Let us consider Figure 5.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 5.1: A Site Multihoming 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 to:
+
+     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 multihoming and mobility in this
+   document.
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 23]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Of course, more complex policies are possible, based on:
+
+    - whether ILNP 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 could be used 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 described in
+   [RFC6740].
+
+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 5.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].
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 24]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+           site                           . . . .      +----+
+          network         SBR            .       .-----+ CN |
+          . . . .      +------+ L1,L2   .         .    +----+
+         .       .     |  sbr1+--------.           .
+        .     H2  .L_L |      |        .           .
+        . H3      .----+  sbr2+--------. Internet  .
+        .         .    |      | L3,L4  .           .
+        .         .    |      |        .           .
+         .  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 5.2: A Site Multihoming Scenario for Traffic Control
+
+   Here, many configurations are possible.  For example, for egress
+   traffic:
+
+     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 rewritten to L2 (and implicitly to use interface sbr1).
+   Expression (5b) maps all egress packets from H3 to have their source
+   Locator value rewritten to L3 (and implicitly to use interface sbr2).
+   Expression (5c) directs any 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 rewritten and packets
+   forwarded in conformance with the routing already configured for the
+   Locator values.
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 25]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Of course, these rules can be changed dynamically at the SBR, and the
+   SBR will migrate ILNP sessions across Locator values, as already
+   described above for mobility.
+
+6.  ILNP in Datacentres
+
+   As ILNP has first class support for mobility and multihoming, and
+   supports flexible options for localised addressing, there is great
+   potential for it to be used in datacentre scenarios.  Further details
+   of possibilities are in [BA12], with a summary presented here.
+
+   There are several scenarios that could be beneficial to datacentres,
+   in order to provide functions such as load balancing, resilience and
+   fault tolerance, and resource management:
+
+   - Same datacentre, internal Virtual Machine (VM) mobility: This could
+     be beneficial in load balancing, dynamically, where load changes
+     are taking place.  The remote user does not see the VM has moved.
+
+   - Different datacentres, transparent mobility: This is where the
+     datacentre resources may be geographically distributed, but the
+     geographical movement is transparent to the remote user.
+
+   - Different datacentres, mobility is visible: This is where the
+     datacentre resources may be geographically distributed, but the
+     geographical movement is visible to the remote user.
+
+   These are three situations that may be supported by ILNP, but they
+   are not the only ones: we provide these here as examples, and they
+   are not intended to be prescriptive.  The intention is only to show
+   the flexibility that is possible through the use of ILNP.
+
+   This section describes some Virtual Machine (VM) mobility
+   capabilities that are possible with ILNP.  Depending on the internal
+   details and virtualisation model provided by a VM platform, it might
+   be sufficient for the guest operating system to support ILNP.  In
+   some cases, again depending on the internal details and
+   virtualisation model provided by a VM platform, the VM platform
+   itself also might need to include support for ILNP.
+
+   Details of how a particular VM platform works, and which
+   virtualisation model(s) a VM platform supports, are beyond the scope
+   of this document.  Internal implementation details of VM platform
+   support for ILNP are also beyond the scope of this document, just as
+   internal implementation details for any other networked system
+   supporting ILNP are beyond the scope of this document.
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 26]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+6.1.  Virtual Image Mobility within a Single Datacentre
+
+   Let us consider first the scenario of Figure 6.1, noting its
+   similarity to Figure 2.1 for use of localised numbering.
+
+          site                         . . . .      +----+
+         network        SBR           .       .-----+ CN |
+         . . . .      +------+ L_1   .         .    +----+
+        .       .     |      +------.           .
+       .    H2   .L_L |      |      .           .
+       .         .----+      |      . Internet  .
+       .  V*H1   .    |      |      .           .
+        .       .     |      |      .           .
+         . . . .      +------+       .         .
+                                      .       .
+                                       . . . .
+
+            CN = Correspondent Node
+             V = Virtual machine image
+            Hx = Host x
+           L_1 = global Locator value
+           L_L = local Locator value
+          SBR = Site Border Router
+
+     Figure 6.1: A Simple Virtual Image Mobility Example for ILNP
+
+   L_L is a Locator value used for the ILNP hosts H1 and H2.  Here, the
+   "V*H1" signifies that the virtual machine image V is currently
+   resident on H1.  Let us assume that V has Identifier I_V.  Note that
+   as H1 and H2 have the same Locator value (L_1), as far as CN is
+   concerned, it does not matter if V is resident on H1 or H2, all
+   transport packets between V and CN will have the same signature as
+   far as CN is concerned, e.g., for a UDP flow (in analogy to (1a)):
+
+     <UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN>           --- (6a)
+
+   Now, if V was to migrate to H2, the migration would be an issue
+   purely local to the site network, and the end-to-end integrity of the
+   transport flow would be maintained.
+
+   Of course, there are practical operating systems issues in enabling
+   such a migration locally, but products exist today that could be
+   modified and made ILNP-aware in order to enable such VM image
+   mobility.
+
+   Note that for convenience, above, we have used localised numbering
+   for ILNP, but if local Locator values were not used and the whole
+   site simply used L_1, the principle would be the same.
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 27]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+6.2.  Virtual Image Mobility between Datacentres - Invisible
+
+   Let us now consider an extended version of the scenario above in Fig.
+   6.2, where we see that there is a second site network, which is
+   geographically distant to the first site network, and the two site
+   networks are interconnected via their respective SBRs.
+
+          site                         . . . .      +----+
+         network 1      SBR1          .       .-----+ CN |
+         . . . .      +------+ L_1   .         .    +----+
+        .       .     |      +------.           .
+       .         .L_L1|      |      .           .
+       .         .----+      |      . Internet  .
+       .  V*H1   .    |      |      .           .
+        .       .     |      |      .           .
+         . . . .      +---+--+      .           .
+                          :         .           .
+                          :         .           .
+         . . . .      +---+--+ L_2  .           .
+        .       .     |      +------.           .
+       .    H2   .L_L2|      |      .           .
+       .         .----+      |      .           .
+       .         .    |      |      .           .
+        .       .     |      |      .           .
+         . . . .      +------+       .         .
+          site          SBR2          .       .
+         network 2                     . . . .
+
+             : = logical inter-router link and coordination
+            CN = Correspondent Node
+             V = Virtual machine image
+            Hx = Host x
+           L_y = global Locator value y
+          L_Lz = local Locator value z
+          SBR = Site Border Router
+
+     Figure 6.2: A Simple Localised Numbering Example for ILNP
+
+   Note that the logical inter-router link between SBR1 and SBR2 could
+   be realised physically in many different ways that are available
+   today and are not ILNP-specific, e.g., leased line, secure IP-layer
+   or Layer 2 tunnel, etc.  We assume that this link also allows
+   coordination between the two SBRs.  For now, we ignore external link
+   L_2 on SBR2, and assume that the remote node, CN, is in communication
+   with V through SBR1.
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 28]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   When in initial communication, the packets have the signature is
+   given in expression (6a).  When V moves to H2, it now uses Locator
+   value L_L2, but all communication between V and CN is still routed
+   via SBR1.  So, the remote CN still sees that same packet signature as
+   given in expression (6a).  L_L1 and L_L2 are, effectively, two
+   internal (private) subnetworks, and are not visible to CN.
+
+   However, SBR2 and SBR1 must coordinate so that any further
+   communication to V via SBR1 is routed across the inter-router link.
+   Again, there are commercial products today that could be adapted to
+   manage such shared state.
+
+6.3.  Virtual Image Mobility between Datacentres - Visible
+
+   Clearly, in the scenario of the section above, once V has moved to
+   site network 2, it may be beneficial, for a number of reasons, for
+   communication to V to be routed via SBR2 rather than SBR1.
+
+   When V moves from site network 1 to site network 2, this visibility
+   of mobility could be by V sending ILNP Locator Update messages to the
+   CN during the mobility process.  Also, V would update any relevant
+   ILNP DNS records, such as L64 records, for new ILNP session requests
+   to be routed via SBR2.
+
+   Indeed, let us now consider again Figure 6.2, and assume now that
+   Local locators L_L1 and L_L2 are not in use on either site network,
+   and each site networks uses its own global Locator value, L_1 and
+   L_2, respectively, internally.  In that case, the packet flow
+   signature for V when it is in site network 1 as viewed from CN is,
+   again as given in expression (6a).  However, when V moves to site
+   network 2, it would simply use L_2 as its new Locator, send Locator
+   Update messages to CN as would a normal mobile node for ILNP, and
+   complete its migration to H2.  Then, CN would see the packet
+   signatures as in expression (6b).
+
+     <UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN>           --- (6b)
+
+   In this case, no "special" inter-router link is required for mobility
+   -- the normal Internet connectivity between SBR1 and SBR2 would
+   suffice.  However, it is quite likely that some sort of tunnelled
+   link would still be desirable to offer protection of the VM image as
+   it migrates.
+
+6.4.  ILNP Capability in the Remote Host for VM Image Mobility
+
+   For the remote host -- the CN -- the availability of ILNP would be
+   beneficial.  However, for the first two scenarios listed above, as
+   the packet signature of the transport flows remains fixed from the
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 29]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   viewpoint of the CN, it seems possible that the benefits of ILNP VM
+   mobility could be used for datacentres even while CNs remain as
+   normal IP hosts.  Of course, a major caveat here is that the
+   application level protocols should be "well behaved": that is, the
+   application protocol or configuration should not rely on the use of
+   IP Addresses.
+
+7.  Location Privacy
+
+   Extending the Locator rewriting 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] [RSG98].
+
+7.1.  Locator Rewriting Relay (LRR)
+
+   To enable this function, we use a middlebox that we call the Locator
+   Rewriting 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>         --- (7a)
+
+              v
+              |
+           +--+--+
+           |     |   src=[I_H, L_1], L_X                   --- (7b)
+           | LRR |   dst=[I_H, L_X], L_1                   --- (7c)
+           |     |
+           +--+--+
+              |
+              v
+      <UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN>         --- (7d)
+
+        LRR = Locator Rewriting Relay
+
+     Figure 7.1: Locator Rewriting Relay (LRR) Example
+
+   The operation of the LRR is conceptually very simple.  We assume that
+   the LRR first has mappings as given in expressions (7b) and (7c) (see
+   next subsection).  Expression (7b) says that for packets with src
+   IL-V [I_H, L_1], the packet's source Locator value should be
+   rewritten to value L_X and then forwarded.  Expression (7c) 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 (7d) is the
+   result of the mapping of packet (7a) using expression (7b).
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 30]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   Note that it is entirely possible that the packet of expression (7d)
+   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
+   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.
+
+7.2.  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 (7b) and (7c).  We consider this function to be outside
+   the scope of these ILNP specifications, but note that there are many
+   existing mechanisms that could modified for use, and also many
+   possibilities for new mechanisms that would be 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, by itself could install the required state, assuming it
+   was aware of suitable information to contact the LRR.  The first
+   packet in an ILNP session might contain a header option called a
+   Locator Redirection Option (LRO).  The LRO would contain the Locator
+   value that should be rewritten 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 an
+   adversary from easily installing false LRR state and causing packets
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 31]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   from H or its correspondent to be subject to man-in-the-middle
+   attacks, or black-holing.  Again, such attacks are not specific to
+   ILNP or new to ILNP.
+
+   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.
+
+8.  Identity Privacy
+
+   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
+   Sections 2 and 11 of [RFC6741].
+
+9.  Security Considerations
+
+   The relevant security considerations to this document are the same as
+   for the main ILNP Architectural Description [RFC6740].  The one
+   additional point to note is that this document describes 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 have the same impact.
+
+   The security considerations for Section 7 (Location Privacy) are
+   already documented in [DMS04] and [RSG98].  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 32]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1918]     Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
+                 G., and E. Lear, "Address Allocation for Private
+                 Internets", BCP 5, RFC 1918, February 1996.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3022]     Srisuresh, P. and K. Egevang, "Traditional IP Network
+                 Address Translator (Traditional NAT)", RFC 3022,
+                 January 2001.
+
+   [RFC3484]     Draves, R., "Default Address Selection for Internet
+                 Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+                 Addresses", RFC 4193, October 2005.
+
+   [RFC4632]     Fuller, V. and T. Li, "Classless Inter-domain Routing
+                 (CIDR): The Internet Address Assignment and Aggregation
+                 Plan", BCP 122, RFC 4632, August 2006.
+
+   [RFC4787]     Audet, F., Ed., and C. Jennings, "Network Address
+                 Translation (NAT) Behavioral Requirements for Unicast
+                 UDP", BCP 127, RFC 4787, January 2007.
+
+   [RFC4864]     Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
+                 and E. Klein, "Local Network Protection for IPv6", RFC
+                 4864, May 2007.
+
+   [RFC4924]     Aboba, B., Ed., and E. Davies, "Reflections on Internet
+                 Transparency", RFC 4924, July 2007.
+
+   [RFC4984]     Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
+                 "Report from the IAB Workshop on Routing and
+                 Addressing", RFC 4984, September 2007.
+
+   [RFC5902]     Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts
+                 on IPv6 Network Address Translation", RFC 5902, July
+                 2010.
+
+   [RFC6177]     Narten, T., Huston, G., and L. Roberts, "IPv6 Address
+                 Assignment to End Sites", BCP 157, RFC 6177, March
+                 2011.
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 33]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   [RFC6740]     Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+                 Protocol (ILNP) Architectural Description", RFC 6740,
+                 November 2012.
+
+   [RFC6741]     Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+                 Protocol (ILNP) Engineering and Implementation
+                 Considerations", RFC 6741, November 2012.
+
+   [RFC6742]     Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource
+                 Records for the Identifier-Locator Network Protocol
+                 (ILNP)", RFC 6742, November 2012.
+
+   [RFC6743]     Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
+                 Message", RFC 6743, November 2012.
+
+   [RFC6744]     Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
+                 Option for the Identifier-Locator Network Protocol for
+                 IPv6 (ILNPv6)", RFC 6744, November 2012.
+
+   [RFC6745]     Atkinson, R. and S. Bhatti,  "ICMP Locator Update
+                 Message for the Identifier-Locator Network Protocol for
+                 IPv4 (ILNPv4)", RFC 6745, November 2012.
+
+   [RFC6746]     Atkinson, R. and S.Bhatti, "IPv4 Options for the
+                 Identifier-Locator Network Protocol (ILNP)", RFC 6746,
+                 November 2012.
+
+   [RFC6747]     Atkinson, R. and S. Bhatti, "Address Resolution
+                 Protocol (ARP) Extension for the Identifier-Locator
+                 Network Protocol for IPv4 (ILNPv4)", RFC 6747, November
+                 2012.
+
+10.2.  Informative References
+
+   [ABH07a]      Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as
+                 an Integrated Service Through the Use of Naming",
+                 Proceedings of ACM Workshop on Mobility in the Evolving
+                 Internet Architecture (MobiArch), ACM SIGCOMM, Kyoto,
+                 Japan. 27 Aug 2007.
+
+   [ABH07b]      Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal
+                 for Unifying Mobility with Multi-Homing, NAT, &
+                 Security", Proceedings of 2nd ACM Workshop on Mobility
+                 Management and Wireless Access (MobiWAC), ACM, Chania,
+                 Crete, Oct 2007.  ISBN: 978-1-59593-809-1
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 34]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   [ABH08a]      Atkinson, R., Bhatti, S., and S. Hailes, "Mobility
+                 Through Naming: Impact on DNS", Proceedings of 3rd ACM
+                 Workshop on Mobility in the Evolving Internet
+                 Architecture (MobiArch), ACM SIGCOMM, Seattle, WA, USA.
+                 Aug 2008.
+
+   [ABH08b]      Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
+                 Resilience, Security, and Mobility Capability for IP",
+                 Proceedings of the IEEE Military Communications
+                 Conference (MILCOM), IEEE, San Diego, CA, USA, Nov
+                 2008.
+
+   [ABH09a]      Atkinson, R, Bhatti, S., and S. Hailes, "Site-
+                 Controlled Secure Multi-Homing and Traffic Engineering
+                 For IP", Proceedings of IEEE Military Communications
+                 Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.
+
+   [ABH09b]      Atkinson, R., Bhatti, S., and S. Hailes, "ILNP:
+                 Mobility, Multi-Homing, Localised Addressing and
+                 Security Through Naming"", Telecommunication Systems",
+                 vol. 42, no. 3-4, pp 273-291, Springer-Verlag, Dec
+                 2009.
+
+   [ABH10]       Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
+                 Internet Architecture Through Naming", IEEE Journal on
+                 Selected Areas in Communication (JSAC), vol. 28, no. 8,
+                 pp 1319-1325, IEEE, Oct 2010.
+
+   [appDNS]      Peterson, J., Kolkman, O., Tschofenig, H., and  B.
+                 Aboba, "Architectural Considerations on Application
+                 Features in the DNS", Work in Progress, July 2012.
+
+   [BA11]        Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
+                 Proceedings of IEEE Global Internet Symposium (GI2011),
+                 Shanghai, P.R. China, 15 Apr 2011.
+
+   [BA12]        Bhatti, S. and R. Atkinson, "Secure & Agile Wide-area
+                 Virtual Machine Mobility", Proceedings of IEEE Military
+                 Communications Conference (MILCOM), Orlando, FL, USA,
+                 Oct 2012.
+
+   [BAK11]       Bhatti, S., Atkinson, R., and J. Klemets, "Integrating
+                 Challenged Networks", Proceedings of IEEE Military
+                 Communications Conference (MILCOM), IEEE, Baltimore,
+                 MD, USA, Nov 2011.
+
+   [BRDP11]      Boot, T. and A. Holtzer, "BRDP Framework", Work in
+                 Progress, January 2011.
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 35]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+   [DMS04]       Dingledine, R., Mathewson, N., and P. Syverson, "Tor:
+                 the second-generation onion router", Proceedings of
+                 13th USENIX Security Symposium, USENIX Association, San
+                 Diego, CA, USA, 2004.
+
+   [IEEE04]      "IEEE 802.1D - IEEE Standard for Local and Metropolitan
+                 Area Networks, Media Access Control (MAC) Bridges",
+                 IEEE Standards Association, New York, NY, USA, 9 June
+                 2004.  Print: ISBN 0-7381-3881-5 SH95213.  PDF: ISBN
+                 0-7381-3982-3 SS95213.
+
+   [LABH06]      Atkinson, R., Lad, M., Bhatti, S., and S. Hailes, "A
+                 Proposal for Coalition Networking in Dynamic
+                 Operational Environments", Proceedings of IEEE Military
+                 Communications Conference (MILCOM), IEEE, Washington,
+                 DC, USA, Nov 2006.
+
+   [mDNS11]      Cheshire, S. and M. Krochmal, "Multicast DNS", Work in
+                 Progress, December 2011.
+
+   [RAB09]       Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling
+                 Mobile Networks Through Secure Naming", Proceedings of
+                 IEEE Military Communications Conference (MILCOM), IEEE,
+                 Boston, MA, USA, Oct 2009.
+
+   [RB10]        Rehunathan, D. and S. Bhatti, "A Comparative Assessment
+                 of Routing for Mobile Networks", Proceedings of 6th
+                 IEEE International Conference on Wireless and Mobile
+                 Computing Networking and Communications (WiMob), IEEE,
+                 Niagara Falls, ON, Canada, Oct 2010.
+
+   [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+                 Addresses", RFC 4193, October 2005.
+
+   [RFC6296]     Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network
+                 Prefix Translation", RFC 6296, June 2011.
+
+   [RSG98]       Reed, M., Syverson, P., and D. Goldschlag, "Anonymous
+                 Connections and Onion Routing", IEEE Journal on
+                 Selected Areas in Communications, Vol. 16, No. 4, IEEE,
+                 Piscataway, NJ, USA, May 1998.
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 36]
+
+RFC 6748                        ILNP ADV                   November 2012
+
+
+11.  Acknowledgements
+
+   Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
+   Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
+   Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
+   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.
+
+   Roy Arends provided expert guidance on technical and procedural
+   aspects of DNS issues.
+
+Authors' Addresses
+
+   RJ Atkinson
+   Consultant
+   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  KY16 9SX
+   Scotland, UK
+
+   EMail: saleem@cs.st-andrews.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 37]
+