Internet Research Task Force (IRTF)                          RJ Atkinson
Request for Comments: 6740                                    Consultant
Category: Experimental                                         SN Bhatti
ISSN: 2070-1721                                            U. St Andrews
                                                           November 2012


  Identifier-Locator Network Protocol (ILNP) Architectural Description

Abstract

   This document provides an architectural description and the concept
   of operations for the Identifier-Locator Network Protocol (ILNP),
   which is an experimental, evolutionary enhancement to IP.  This is a
   product of the IRTF Routing Research Group.

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/rfc6740.

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.

Table of Contents

   1. Introduction ....................................................3
      1.1. Document Roadmap ...........................................5
      1.2. History ....................................................6
      1.3. Terminology ................................................7
   2. Architectural Overview ..........................................7
      2.1. Identifiers and Locators ...................................7
      2.2. Deprecating IP Addresses ...................................9
      2.3. Session Terminology .......................................10
      2.4. Other Goals ...............................................12
   3. Architectural Changes Introduced by ILNP .......................12
      3.1. Identifiers ...............................................12
      3.2. Locators ..................................................14
      3.3. IP Address and Identifier-Locator Vector (I-LV) ...........16
      3.4. Notation ..................................................16
      3.5. Transport-Layer State and Transport Pseudo-Headers ........18
      3.6. Rationale for This Document ...............................18
      3.7. ILNP Multicasting .........................................19
   4. ILNP Basic Connectivity ........................................20
      4.1. Basic Local Configuration .................................20
      4.2. I-L Communication Cache ...................................21
      4.3. Packet Forwarding .........................................22
      4.4. Packet Routing ............................................23
   5. Multihoming and Multi-Path Transport ...........................24
      5.1. Host Multihoming (H-MH) ...................................25
      5.2. Support for Multi-Path Transport Protocols ................27
      5.3. Site Multihoming (S-MH) ...................................28
      5.4. Multihoming Requirements for Site Border Routers ..........29
   6. Mobility .......................................................30
      6.1. Mobility / Multihoming Duality in ILNP ....................31
      6.2. Host Mobility .............................................32

      6.3. Network Mobility ..........................................34
      6.4. Mobility Requirements for Site Border Routers .............36
      6.5. Mobility with Multiple SBRs ...............................36
   7. IP Security for ILNP ...........................................36
      7.1. Adapting IP Security for ILNP .............................37
      7.2. Operational Use of IP Security with ILNP ..................37
   8. Backwards Compatibility and Incremental Deployment .............38
   9. Security Considerations ........................................39
      9.1. Authentication of Locator Updates .........................39
      9.2. Forged Identifier Attacks .................................40
      9.3. IP Security Enhancements ..................................42
      9.4. DNS Security ..............................................42
      9.5. Firewall Considerations ...................................42
      9.6. Neighbour Discovery Authentication ........................42
      9.7. Site Topology Obfuscation .................................43
   10. Privacy Considerations ........................................43
      10.1. Location Privacy .........................................43
      10.2. Identity Privacy .........................................44
   11. References ....................................................45
      11.1. Normative References .....................................45
      11.2. Informative References ...................................47
   12. Acknowledgements ..............................................53

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.

   There has been substantial research relating to naming in the
   Internet through the years [IEN1] [IEN19] [IEN23] [IEN31] [IEN135]
   [RFC814] [RFC1498] [RFC2956].  Much of that research has indicated
   that binding the end-to-end transport-layer session state with a
   specific interface of a node at a specific location is undesirable,
   for example, creating avoidable issues for mobility, multihoming, and
   end-to-end security.  More recently, mindful of that important prior
   work, and starting well before the Routing RG was re-chartered to
   focus on inter-domain routing scalability, the authors have been
   examining enhancements to certain naming aspects of the Internet
   Architecture.  Separately, the Internet Architecture Board (IAB)
   recently considered the matter of Internet evolution, including
   naming [RFC6250].

   Our ideas and progress so far are embodied in the ongoing definition
   of an experimental protocol that we call the Identifier-Locator
   Network Protocol (ILNP).

   Links to relevant material are all available at:
      http://ilnp.cs.st-andrews.ac.uk/

   At the time of writing, the main body of peer-reviewed research from
   which the ideas in this and the accompanying documents draw is given
   in [LABH06], [ABH07a], [ABH07b], [ABH08a], [ABH08b], [ABH09a],
   [ABH09b], [RAB09], [ABH10], [RB10], [BA11], [BAK11], and [BA12].

   In this document, we:

      a) describe the architectural concepts behind ILNP and how various
         ILNP capabilities operate: this document deliberately focuses
         on describing the key architectural changes that ILNP
         introduces and defers engineering discussion to separate
         documents.

   Other documents (listed below):

      b) show how functions based on ILNP would be realised on today's
         Internet by proposing an instance of ILNP based on IPv6, which
         we call ILNPv6 (there is also a document describing ILNPv4,
         which is how ILNP could be applied to IPv4).

      c) discuss salient operational and engineering issues impacting
         the deployment of ILNPv6 and the impact on the Internet.

      d) give architectural descriptions of optional advanced
         capabilities in advanced deployments based on the ILNP
         approach.

1.1.  Document Roadmap

   This document describes the architecture for the Identifier-Locator
   Network Protocol (ILNP) including concept of operations.  The authors
   recommend reading and understanding this document as the starting
   point to understanding ILNP.

   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) [RFC6741] describes engineering and implementation considerations
      that are common to both ILNPv4 and ILNPv6.

   b) [RFC6742] defines additional DNS resource records that support
      ILNP.

   c) [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.

   d) [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.

   e) [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.

   f) [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.

   g) [RFC6747] describes extensions to the Address Resolution Protocol
      (ARP) for use with ILNPv4.

   h) [RFC6748] describes optional engineering and deployment functions
      for ILNP.  These are not required for the operation or use of ILNP
      and are provided as additional options.

1.2.  History

   In 1977, Internet researchers at University College London wrote the
   first Internet Experiment Note (IEN), which discussed issues with the
   interconnection of networks [IEN1].  This identified the inclusion of
   network-layer addresses in the transport-layer session state (e.g.,
   TCP checksum) as a significant problem for mobile and multihomed
   nodes and networks.  It also proposed separation of identity from
   location as a better approach to take when designing the TCP/IP
   protocol suite.  Unfortunately, that separation did not occur, so the
   deployed IPv4 and IPv6 Internet entangles upper-layer protocols
   (e.g., TCP, UDP) with network-layer routing and topology information
   (e.g., IP Addresses) [IEN1] [RFC768] [RFC793].

   The architectural concept behind ILNP derives from a June 1994 note
   by Bob Smart to the IETF SIPP WG mailing list [SIPP94].  In January
   1995, Dave Clark sent a similar note to the IETF IPng WG mailing
   list, suggesting that the IPv6 address be split into separate
   Identifier and Locator fields [IPng95].

   Afterwards, Mike O'Dell pursued this concept in Internet-Drafts
   describing "8+8" [8+8] and "GSE" (Global, Site, and End-system)
   [GSE].  More recently, the IRTF Namespace Research Group (NSRG)
   studied this matter around the turn of the century.  Unusually for an
   IRTF RG, the NSRG operated on the principle that unanimity was
   required for the NSRG to make a recommendation.  Atkinson was a
   member of the IRTF NSRG.  At least one other protocol, the Host
   Identity Protocol (HIP), also derives in part from the IRTF NSRG
   studies (and related antecedent work).  This current proposal differs
   from O'Dell's work in various ways, notably in that it does not
   require deployment or use of Locator rewriting.

   The key idea proposed for ILNP is to directly and specifically change
   the overloaded semantics of the IP Address.  The Internet community
   has indicated explicitly, several times, that this use of overloaded
   semantics is a significant problem with the use of the Internet
   protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984].

   While the research community has made a number of proposals that
   could provide solutions, so far there has been little progress on
   changing the status quo.

1.3.  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.  Architectural Overview

   ILNP takes a different approach to naming of communication objects
   within the network stack.  Two new data types are introduced which
   subsume the role of the IP Address at the network and transport
   layers in the current IP architecture.

2.1.  Identifiers and Locators

   ILNP explicitly replaces the use of IP Addresses with two distinct
   name spaces, each having distinct and different semantics:

      a) Identifier: a non-topological name for uniquely identifying a
         node.

      b) Locator: a topologically bound name for an IP subnetwork.

   The use of these two new namespaces in comparison to IP is given in
   Table 1.  The table shows where existing names are used for state
   information in end-systems or protocols.

           Layer     |          IP          |     ILNP
      ---------------+----------------------+---------------
        Application  |  FQDN or IP Address  |  FQDN
        Transport    |  IP Address          |  Identifier
        Network      |  IP Address          |  Locator
        Physical i/f |  IP Address          |  MAC address
      ---------------+----------------------+---------------

      FQDN = Fully Qualified Domain Name
      i/f = interface
      MAC = Media Access Control

      Table 1: Use of Names for State Information in Various
              Communication Layers for IP and ILNP

   As shown in Table 1, if an application uses a Fully Qualified Domain
   Name at the application-layer, rather than an IP Address or other
   lower-layer identifier, then the application perceives no
   architectural difference between IP and ILNP.  We call such
   applications "well-behaved" with respect to naming as use of the FQDN
   at the application-layer is recommended in [RFC1958].  Some other
   applications also avoid use of IP Address information within the
   application-layer protocol; we also consider these applications to be
   "well-behaved".  Any well-behaved application should be able to
   operate on ILNP without any changes.  Note that application-level use
   of IP Addresses includes application-level configuration information,
   e.g., Apache web server (httpd) configuration files make extensive
   use of IP Addresses as a form of identity.

   ILNP does not require applications to be rewritten to use a new
   Networking Application Programming Interface (API).  So existing
   well-behaved IP-based applications should be able to work over ILNP
   as is.

   In ILNP, transport-layer protocols use only an end-to-end, non-
   topological node Identifier in any transport-layer session state.  It
   is important to note that the node Identifier names the node, not a
   specific interface of the node.  In this way, it has different
   semantics and properties than either the IPv4 address, the IPv6
   address, or the IPv6 interface identifier [RFC791] [RFC4291].

   The use of the ILNP Identifier value within application-layer
   protocols is not recommended.  Instead, the use of either a FQDN or
   some different topology-independent namespace is recommended.

   At the network-layer, Locator values, which have topological
   significance, are used for routing and forwarding of ILNP packets,
   but Locators are not used in upper-layer protocols.

   As well as the new namespaces, another significant difference in
   ILNP, as shown in Table 1, is that there is no binding of a routable
   name to an interface, or Sub-Network Point of Attachment (SNPA), as
   there is in IP.  The existence of such a binding in IP effectively
   binds transport protocol flows to a specific, single interface on a
   node.  Also, applications that include IP Addresses in their
   application-layer session state effectively bind to a specific,
   single interface on a node [RFC2460] [RFC6724].

   In ILNP, dynamic bindings exist between Identifier values and
   associated Locator values, as well as between {Identifier, Locator}
   pairs and (physical or logical) interfaces on the node.

   This change enhances the Internet Architecture by adding crisp and
   clear semantics for the Identifier and for the Locator, removing the
   overloaded semantics of the IP Address [RFC1992] [RFC4984], by
   updating end-system protocols, but without requiring any router or
   backbone changes.  In ILNP, the closest approximation to an IP
   Address is an I-L Vector (I-LV), which is a given binding between an
   Identifier and Locator pair, written as [I, L].  I-LVs are discussed
   in more detail below.

   Where, today, IP packets have:

   - Source IP Address, Destination IP Address

   instead, ILNP packets have:

   - source I-LV, destination I-LV

   However, it must be emphasised that the I-LV and the IP Address are
   *not* equivalent.

   With these naming enhancements, we will improve the Internet
   Architecture by adding explicit harmonised support for many
   functions, such as multihoming, mobility, and IPsec.

2.2.  Deprecating IP Addresses

   ILNP places an explicit Locator and Identifier in the IP packet
   header, replacing the usual IP Address.  Locators are tied to the
   topology of the network.  They may change frequently, as the node or
   site changes its network connectivity.  The node Identifier is
   normally much more static and remains constant throughout the life of
   a given transport-layer session, and frequently much longer.
   However, there are various options for Identifier values, as
   discussed in [RFC6741].  The way that I-LVs are encoded into packet
   headers is different for IPv4 and IPv6, as explained in [RFC6741].

   Identifiers and Locators for hosts are advertised explicitly in DNS,
   through the use of new Resource Records (RRs).  This is a logical and
   reasonable use of DNS, completely analogous to the capability that
   DNS provides today.  At present, among other current uses, the DNS is
   used to map from an FQDN to a set of addresses.  As ILNP replaces IP
   Addresses with Identifiers and Locators, it is then clearly rational
   to use the DNS to map an FQDN to a set of Identifiers and a set of
   Locators for a node.

   The presence of ILNP Locators and Identifiers in the DNS for a DNS
   owner name is an indicator to correspondents that the correspondents
   can try to establish an ILNP-based transport-layer session with that
   DNS owner name.

   Specifically in response to [RFC4984], ILNP improves routing
   scalability by helping multihomed sites operate effectively with
   Provider Aggregated (PA) address prefixes.  Many multihomed sites
   today request provider-independent (PI) address prefixes so they can
   provide session survivability despite the failure of one or more
   access links or Internet Service Providers (ISPs).  ILNP provides
   this transport-layer session survivability by having a provider-
   independent Node Identifier (NID) value that is free of any
   topological semantics.  This NID value can be bound dynamically to a
   Provider Aggregated Locator (L) value, the latter being a topological
   name, i.e., a PA network prefix.  By allowing correspondents to
   change arbitrarily among multiple PA Locator values, survivability is
   enabled as changes to the L values need not disrupt transport-layer
   sessions.  In turn, this allows an ILNP multihomed site to have both
   the full transport-layer and full network-layer session resilience
   that is today offered by PI addressing while using the equivalent of
   PA addressing.  In turn, this eliminates the current need to use
   globally visible PI routing prefixes for each multihomed site.

2.3.  Session Terminology

   To improve clarity and readability of the several ILNP specification
   documents, this section defines the terms "network-layer session" and
   "transport-layer session" both for IP-based networks and ILNP-based
   networks.

   Today, network-layer IP sessions have 2 components:

   - Source IP Address (A_S)
   - Destination IP Address (A_D)

   For example, a tuple for an IP layer session would be:

      <IP: A_S, A_D>

   Instead, network-layer ILNP sessions have 4 components:

   - Source Locator(s) (L_S)
   - Source Identifier(s) (I_S)
   - Destination Locator(s) (L_D)
   - Destination Identifier(s) (L_S)

   and a tuple for an ILNP session would be:

      <ILNP: I_S, L_S, I_D, L_D>

   The phrase "ILNP session" refers to an ILNP-based network-layer
   session, having the 4 components in the definition above.

   For engineering efficiency, multiple transport-layer sessions between
   a pair of ILNP correspondents normally share a single ILNP session
   (I-LV pairs and associated Nonce values).  Also, for engineering
   convenience (and to cope with situation where different nodes, at
   different locations, might use the same I values), in the specific
   implementation of ILNPv6 and ILNPv4, we define the use of nonce
   values:

   - Source-to-destination Nonce value (N_S)
   - Destination-to-source Nonce value (N_D)

   These are explained in more detail in [RFC6741], with [RFC6744] for
   ILNPv6 and [RFC6746] for ILNPv4.

   Today, transport-layer sessions using IP include these 5 components:

    - Source IP Address (A_S)
    - Destination IP Address (A_D)
    - Transport-layer protocol (e.g., UDP, TCP, SCTP)
    - Source transport-layer port number (P_S)
    - Destination transport-layer port number (P_D)

   For example, a TCP tuple would be:

      <TCP: P_S, P_D, A_S, A_D>

   Instead, transport-layer sessions using ILNP include these 5
   components:

   - Source Identifier (I_S)
   - Destination Identifier (I_D)
   - Transport-layer protocol (e.g., UDP, TCP, SCTP)
   - Source transport-layer port number (P_S)
   - Destination transport-layer port number (P_D)

   and an example tuple:

      <TCP: P_S, P_D, I_S, I_D>

2.4.  Other Goals

   While we seek to make significant enhancements to the current
   Internet Architecture, we also wish to ensure that instantiations of
   ILNP are:

      a) Backwards compatible: implementations of ILNP should be able to
         work with existing IPv6 or IPv4 deployments, without requiring
         application changes.

      b) Incrementally deployable: to deploy an implementation of ILNP,
         changes to the network nodes should only be for those nodes
         that choose to use ILNP.  The use of ILNP by some nodes does
         not require other nodes (that do not use ILNP) to be upgraded.