GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6748

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:
  1. whether ILNP sessions are incoming or outgoing
  2. time of day
  3. 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:
  1. destination I values could be used
  2. source or destination L values could be used
  3. 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:
  1. 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.
  1. Different datacentres, transparent mobility: This is where the

datacentre resources may be geographically distributed, but the

   geographical movement is transparent to the remote user.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6748.txt · Last modified: 2012/11/10 00:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki