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

Versions: 00 01 02 03 04

Network Working Group                                            S. Brim
Internet-Draft                                                N. Chiappa
Intended status: Experimental                               D. Farinacci
Expires: January 17, 2008                                      V. Fuller
                                                                D. Lewis
                                                                D. Meyer
                                                           July 16, 2007


   LISP-CONS: A Content distribution Overlay Network Service for LISP
                      draft-meyer-lisp-cons-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Content distribution Overlay Network Service for LISP (LISP-CONS)
   is a protocol for distributing identifier-to-locator mappings for the
   Locator/ID Separation Protocol (LISP).  LISP-CONS is not a routing
   protocol.  LISP-CONS is designed to scale by using a hierarchical
   content distribution system comprised of Tunnel Routers, Content



Brim, et al.            Expires January 17, 2008                [Page 1]


Internet-Draft                  LISP-CONS                      July 2007


   Access Resources, and Content Distribution Resources.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  LISP-CONS Name Spaces  . . . . . . . . . . . . . . . . . .  5
     3.2.  LISP-CONS Network Elements . . . . . . . . . . . . . . . .  5
     3.3.  Relationship Between LISP-CONS Network Elements  . . . . .  7
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  7
   5.  The LISP-CONS Protocol . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Building the LISP-CONS Database  . . . . . . . . . . . . . 10
     5.2.  Querying the LISP-CONS Database  . . . . . . . . . . . . . 11
     5.3.  Maintaining the LISP-CONS Database . . . . . . . . . . . . 12
       5.3.1.  An EID-Prefix Is Administratively Removed From The
               Infrastructure . . . . . . . . . . . . . . . . . . . . 13
       5.3.2.  A CAR's Connectivity Changes . . . . . . . . . . . . . 14
       5.3.3.  A CAR Becomes Unreachable  . . . . . . . . . . . . . . 15
       5.3.4.  A CDR Becomes Unreachable  . . . . . . . . . . . . . . 15
   6.  LISP-CONS Message Types  . . . . . . . . . . . . . . . . . . . 16
     6.1.  Open Message . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2.  Push-Add and Push-Delete . . . . . . . . . . . . . . . . . 19
     6.3.  Map-Request Message  . . . . . . . . . . . . . . . . . . . 20
     6.4.  Map-Reply Message  . . . . . . . . . . . . . . . . . . . . 22
     6.5.  Unreachable Message  . . . . . . . . . . . . . . . . . . . 25
   7.  Operational Considerations . . . . . . . . . . . . . . . . . . 26
   8.  LISP-CONS and Locator Reachability . . . . . . . . . . . . . . 26
   9.  LISP-CONS and Mobility . . . . . . . . . . . . . . . . . . . . 26
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 27
     12.1. Apparent LISP-CONS Vunerabilities  . . . . . . . . . . . . 27
     12.2. Survey of LISP-CONS Security Mechanisms  . . . . . . . . . 28
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     14.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 31










Brim, et al.            Expires January 17, 2008                [Page 2]


Internet-Draft                  LISP-CONS                      July 2007


1.  Requirements Notation

   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.  Introduction

   The Content distribution Overlay Network Service for LISP, or LISP-
   CONS, is a control-plane protocol for distributing identifier-to-
   locator mappings for the Locator/ID Separation Protocol (LISP)
   [LISP-02].  The properties of such a "locator/id split" have been
   discussed in depth in various venues dating back to [CHIAPPA] and
   [RFC1498], and as such will not be reviewed here.  Rather, the reader
   is referred to the above references for an outline of the various
   benefits that may be realized by separating the functionality of IP
   addresses into separate Endpoint Identifier and Routing Locator name
   spaces.

   LISP-CONS operates on a distributed Endpoint Identifier-to-Routing
   Locator (EID-to-RLOC) database.  This database is distributed among
   the authoritative Replying Content Access Resources (Replying-CAR).
   A Replying-CAR (rCAR) advertises "reachability" for its EID-to-RLOC
   mappings through a hierarchical network of Content Distribution
   Resources (CDRs) (but importantly, not the mapping itself), and
   responds to mapping requests from the system.  A CAR may also request
   mappings from the system (this a Querying-CAR, or qCAR).  Ingress
   Tunnel Routers (ITRs) connect to one or more qCARs to query the
   system for EID-to-RLOC bindings; the qCAR then queries the system on
   behalf of the ITR.  These queries follow the overlay network to the
   authoritative rCAR, which responds with the mapping.  This response
   may then be cached by the 'local' CAR.  Finally, note that neither a
   qCAR or rCAR need to hold the entire EID-to-RLOC database.  Rather,
   the EID-to-RLOC translations are explicitly pulled by the ITRs by
   querying one or more of its connected qCARs.

   Note that LISP-CONS is not designed for the "fast-mobility" case.
   That is, it is envisioned that the mappings distributed by LISP-CONS
   are reasonably static.  LISP-CONS is also not designed to carry
   Locator Reachability status information; see [LISP-02] for details on
   how LISP determines locator reachability.

   LISP-CONS seeks to control the "state * rate" scaling properties of
   the mapping service by first observing that the host mapping state is
   likely to be quite large (some estimates put the size of this
   database to be on the order of 10^10 hosts).  As a result, even with
   aggressive aggregation, the "rate" of change of the mapping database



Brim, et al.            Expires January 17, 2008                [Page 3]


Internet-Draft                  LISP-CONS                      July 2007


   must be kept small.  LISP-CONS manages the rate problem by
   distributing highly aggregated information about the location of the
   EID-to-RLOC mappings (which are assumed to change at low frequency)
   over a peering network.  The peering network is comprised of ITRs,
   CARs and CDRs.

   In summary, LISP-CONS is a hybrid "push/pull" protocol in which
   information about the existence of a particular mapping is "pushed"
   at the higher levels of the aggregation hierarchy, while the actual
   EID-to-RLOC mappings are "pulled" from the network elements at the
   lowest level of the hierarchy.  In particular, LISP-CONS carries
   mapping requests and replies to and from the lowest level of the
   hierarchy where the EID-to-RLOC mappings reside.

   While this draft focuses on a router-based solution, there is no
   architectural reason that LISP-CONS functionality could not be
   implemented in other devices (i.e., hosts).  However, in keeping with
   the architectural direction taken by the LISP data-plane proposal
   [LISP-02], LISP-CONS is based on the the theory that building the
   solution into the network should facilitate incremental deployment of
   the technology on the Internet.  In order to minimize the required
   investment in deployment of new hardware, it is assumed that much, if
   not all, the initial implementation will be in routers.  Finally,
   while the detailed protocol specification and examples in this
   document assume IP version 4 (IPv4), there is nothing in the design
   that precludes the use of the same techniques and mechanisms for
   IPv6.

   The remainder of this document is organized as follows: Section 3
   provides the set of definitions that are used in this document, and
   Section 4 provides an overview of LISP-CONS operation.  Section 5
   describes the LISP-CONS protocol, and Section 6 provides details of
   the LISP-CONS message types.  Section 7 outlines operational
   considerations, Section 8 discusses locator reachability, and
   Section 9 considers the interaction of LISP-CONS with mobile nodes.
   Section 12 outlines security considerations for LISP-CONS.

   Finally, this proposal (as well as the LISP data-plane proposal) was
   stimulated by the problem statement effort at the IAB Routing and
   Addressing Workshop (RAWS) [I-D.iab-raws-report], which took place in
   Amsterdam in October 2006.


3.  Definition of Terms

   The LISP-CONS protocol operates on two name spaces and is comprised
   of four network elements.  This section provides high-level
   definitions of the LISP-CONS name spaces, network elements, and



Brim, et al.            Expires January 17, 2008                [Page 4]


Internet-Draft                  LISP-CONS                      July 2007


   message types.

3.1.  LISP-CONS Name Spaces

    Endpoint ID (EID):  A 32- or 128-bit value used in the source and
      destination fields of the first (most inner) LISP header of a
      packet.  A packet that is emitted by a system contains EIDs in its
      headers and and LISP headers are prepended only when the packet
      hits an Ingress Tunnel Router (ITR) on the data path to the
      destination EID.

      In LISP-CONS, EID-prefixes MUST BE assigned in a hierarchical
      manner (in power-of-two or larger chunks) such that they can be
      aggregated either by Content Access Resources or Content
      Distribution Resources (see below).  In addition, a site may have
      site-local structure in how EIDs are topologically organized
      (subnetting) for routing within the site; this structure is not
      visible to the global routing system.

   EID-Prefix Aggregate:  A set of EID-prefixes said to be aggregatable
      in the [RFC4632] sense.  That is, an EID-Prefix aggregate is
      defined to be a single contiguous power-of-two EID-prefix block.
      Such a block is characterized by a prefix and a mask.

   Routing Locator (RLOC):  The IP address of an egress tunnel router
      (ETR).  It is the output of a EID-to-RLOC mapping lookup.  An EID
      maps to one or more RLOCs.  Typically, RLOCs are numbered from
      topologically-aggregatable blocks that are assigned to a site at
      each point to which it attaches to the global Internet; where the
      topology is defined by the connectivity of provider networks,
      RLOCs can be thought of as Provider Aggregatable (PA) addresses.

    EID-to-RLOC Mapping:  A binding between and EID and the RLOC-set
      that can be used to reach the EID.  We use the term "mapping" in
      this document to refer to a EID-to-RLOC mapping.

3.2.  LISP-CONS Network Elements

   LISP-CONS consists of the four network element types described below.
   Peering connections between these element types use RLOCs so that the
   underlying routing system can keep the LISP-CONS peering connections
   up (i.e., to avoid circular dependencies on the mapping system).
   Each peering connection is required to be configured with a keyed-
   hash message authentication code (HMAC) key.  A connection MUST NOT
   be established without the TCP HMAC option included.






Brim, et al.            Expires January 17, 2008                [Page 5]


Internet-Draft                  LISP-CONS                      July 2007


   Content Distribution Resource (CDR):  A CDR provides aggregation of
      EID prefix lists, propagation of EID-prefix lists to parent CDRs,
      and routing of mapping requests to and from CARs.

      There may be several levels of aggregation of CDRs.  CDRs do not
      themselves carry EID prefix to RLOC mappings.  CDRs are arranged
      in a hierarchical manner in order to enable aggressive aggregation
      of EID-prefixes.

   Content Access Resource (CAR):  A CAR fills one or both of the
      following roles:

      Replying-CAR (rCAR):  A CAR is the source of authority for one or
         more EID prefix to RLOC mappings which which it has been
         administratively configured, and responds to Map Requests for
         these EID-to-RLOC mappings.  Each rCAR provides to parent CDRs
         a list of prefixes that it is responsible for, but not the
         mappings themselves.

         In particular, rCARs peer with CDRs to propagate aggregated
         information about how to find a particular EID-to-RLOC mapping
         upward (but importantly, not the mapping itself).  However,
         rCARs do not peer with other CARs.  The primary difference
         between the rCAR and CDR is that a CAR maintains two databases:
         A EID-to-RLOC mapping database, and a EID-prefix database.  A
         CDR maintains only an EID-prefix database.

      Querying-CAR (qCAR):  A CAR that generates Map-Request messages on
         behalf of one or more of its ITR peers (see below).  Note that
         qCAR has peering connections with ITRs whereas a rCAR does not
         have to.  Finally, both functionalities (qCAR and rCAR) MAY be
         co-located in the same device.  In particular, qCAR MUST also
         be a rCAR, while a a rCAR need not be a qCAR.

   Egress Tunnel Router (ETR):  A router that accepts an IP packet where
      destination address in the "outer" IP header is one of its own
      RLOCs.  The router strips the "outer" header and forwards the
      packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.

   Ingress Tunnel Router (ITR):  A router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the



Brim, et al.            Expires January 17, 2008                [Page 6]


Internet-Draft                  LISP-CONS                      July 2007


      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping
      closest to the destination EID.  In general, an ITR receives IP
      packets from site end-systems on one side and sends LISP-
      encapsulated IP packets toward the Internet on the other side.
      ITRs may also have TCP connections to qCARs in order to send
      mapping requests and receive replies (noting that a qCAR, a rCAR,
      and an ITR may be co-located).

3.3.  Relationship Between LISP-CONS Network Elements

   Each LISP-CONS device is known by a single identifier, which is used
   for peering from all peers, and in path-vector (PV) lists.  This
   identifier MAY be an IP address.  An implementation SHOULD use a
   loopback address for this purpose.  Note that this address MUST be
   routable by the core routing system.

   LISP-CONS network elements peer with each other in one of three
   peering relationships: parent, child, or sibling.  The relationship
   is carried in the LISP-CONS OPEN message (Section 6.1).  The
   permitted peering relationships are as follows:

   o  ITRs exist at lowest (unnumbered) level in the peering hierarchy,
      and peer only with one or more CARs.  An ITR MUST NOT peer with
      another ITR or with a CDR.

   o  CARs exist at level 0 in the peering hierarchy, and peer only with
      parent CDRs or with a child ITR.  A CAR MUST NOT peer with another
      CAR; this rule allows the rCARs to aggregate EID prefixes as low
      in the hierarchy as possible.  Note that this rule also means that
      mapping requests and replies are routed over the peering topology,
      not directly between the CARs.

   o  CDRs exist at level 1 (and above) and aggregate EID-prefixes learn
      from its rCAR peerings.  When a two CDRs start their peering
      connection, if one is a parent, the other MUST BE a child.
      Otherwise, they both MUST BE siblings.

   o  If any of these checks fail, the peering connection MUST NOT be
      established.


4.  Overview of Operation

   LISP-CONS constructs a multi-level content distribution overlay which
   achieves scalability by imposing a strict aggregation hierarchy on
   the participating elements.  The LISP-CONS hierarchy consists of ITRs



Brim, et al.            Expires January 17, 2008                [Page 7]


Internet-Draft                  LISP-CONS                      July 2007


   the bottom of the hierarchy, CARs at level 0, and CDRs at levels 1
   and above; this is depicted in Figure 1.  Each level of the hierarchy
   is a strict tree.  That is, there are no transit loops in the
   hierarchy; redundancy is achieved by meshing CDR connectivity within
   in a single level of the hierarchy, and the LISP-CONS protocol
   assures that message flow is loop-free.

   In LISP-CONS, the EID-to-RLOC mappings are held in the rCARs, while
   the CDRs maintain information about how to find the rCAR holding a
   particular EID-to-RLOC mapping.  That is, the Push-Add and Push-
   Delete messages (Section 6.2) only contain EID-prefixes (i.e.,
   Locator-sets are not included in these messages and are not stored in
   the CDRs).

   In general, LISP-CONS uses network element redundancy to avoid
   mapping database inconsistencies that may arise in those cases in
   which a CAR or CDR crashes.  Similarly, connectivity outages are
   avoided by configuring a redundant underlying topology.


                 +----------------+
                 | CDR ------ CDR |
                 +--|----------|--+
                   /            \
                  /              \
    +----------------+         +----------------+
    | CDR ------ CDR |         | CDR ------ CDR |   (CDR-mesh at level 2)
    +--|----------|--+         +--|----------|--+
       |          |               |          |
       |          |               |          |
   +---|----------|----+      +---|----------|---+
   |  CDR ------ CDR   |      |  CDR ------ CDR  |
   |   |          |    |      |   |          |   |  (CDR-Mesh at level 1)
   |   |          |    |      |   |          |   |
   |  CDR ------ CDR   |      |  CDR ------ CDR  |
   +---|----------|----+      +---|----------|---+
       |          |               |          |
       |          |               |          |
       |          |               |          |
      CAR        CAR             CAR        CAR
      / \        / \             / \        / \
     /   \      /   \           /   \      /   \
   ITR   ITR  ITR   ITR       ITR   ITR  ITR   ITR


                       Figure 1: LISP-CONS Hierarchy

   Figure 2 depicts the details of the first three levels of hierarchy.



Brim, et al.            Expires January 17, 2008                [Page 8]


Internet-Draft                  LISP-CONS                      July 2007


   Note that there are no horizontal TCP connections between the ITRs or
   between the CARs.  Note that qCARs (abbreviated "Req-CAR") peer with
   the ITRs, while the rCARs may not.  The CDRs at level 1 are meshed so
   that the two rCARs can aggregate to the same mesh level.

                             CDR --- CDR (level-1)
                              |\     /|
                              | \   / |
                              |  \ /  |
                              |   X   |
                              |  / \  |
                              | /   \ |
                              |/     \|
                             CAR     CAR (level-0)
                              |\     /|
                              | \   / |
                              |  \ /  |
                              |   X   |
                              |  / \  |
                              | /   \ |
                              |/     \|
                             ITR     ITR

                   Figure 2: LISP-CONS Hierarchy Detail

   LISP-CONS operates as follows: A rCAR receives EID-to-RLOC mappings
   by administrative configuration.  The rCARs aggregate these EID-
   prefixes into power-of-two less specific EID-prefixes, and "push" the
   aggregated EID-prefixes to their (parent) CDRs in Push-Add messages
   (see Section 6.2).  CDRs then flood the Push-Add messages to their
   sibling CDRs.  Note that the Push messages contain EID-prefix
   reachability information, not locator sets.

   If a CDR is a child, it then pushes the aggregate for the EID-prefix
   (i.e., the aggregate that "covers" the EID-prefix) to its parent
   CDRs.  This CDR MUST also originate the default EID-prefix 0.0.0.0/0
   or 0::0/0 (this allows Requests and Replies to flow up and down the
   aggregation hierarchy).  This default is contained within the level
   of the sibling mesh.  Note that aggregates MUST only be generated
   when the components of the aggregate are all longer prefixes than the
   aggregate (and importantly, NOT equal in length).  For example, a CDR
   MUST NOT generate an aggregate such as A.B.0.0/16 if it has not heard
   a A.B.*.0/24 from either a child or sibling peer.

   When an ITR needs a mapping, it sends a Map-Request message to its
   directly connected qCARs.  If any of those CARs have cached the
   requested mapping, the result is immediately returned to the ITR.
   Otherwise, the Map-Request message is routed through the CDR



Brim, et al.            Expires January 17, 2008                [Page 9]


Internet-Draft                  LISP-CONS                      July 2007


   hierarchy to the rCAR which holds the mapping.  That CAR then returns
   the mapping in a Map-Reply message (which is routed over the peering
   topology) to the qCAR, which then forwards it on to the requesting
   ITR.

   Finally, note that this type of advertisement hierarchy allows EID
   lookups to have lower Round Trip Times (RTTs) when the EID-prefix is
   "close" (in the EID allocation hierarchy) to the site's attached CAR.
   However, for scalability reasons, a request may have to travel extra
   hops to get an EID-prefix that can only be obtained by going up the
   tree (and in the worse case, by going to the top of the hierarchy and
   down to the rCAR that hold the mapping).


5.  The LISP-CONS Protocol

   This section describes the LISP-CONS protocol in detail, starting
   with how LISP-CONS builds a distributed mapping database, how an ITR
   queries the database, and how the database is maintained.

   LISP-CONS operates on three different data structures:

   EID-to-RLOC Database:  The EID-to-RLOC mapping database, which is
      administratively configured and held in the rCARs.

   Mapping Cache:  The Mapping Cache (hereafter cache) is the result of
      a Map-Request and is stored in the ITRs and qCARs.

   EID-Prefix Table:  The EID-Prefix table is used to route Map-Requests
      and Map-Replies in the overlay network.  It is stored only by
      CDRs, and associates an EID-prefix with a 64-bit sequence number,
      a path-vector, and a priority and weight (to facilitate later
      aggregation, if possible).

5.1.  Building the LISP-CONS Database

   When a rCAR is configured with an EID-to-RLOC mapping, it checks to
   see if it can aggregate the just learned EID-prefix with any of the
   other EID-prefixes it has been configured with.  The CAR then sends
   ("pushes") the EID-prefix (or an aggregate, if possible) to its
   parent CDR in a Push-Add message.

   A rCAR generates an aggregate when it has at least one more specific
   prefix that matches the aggregate.  A more specific prefix of an
   aggregate is when the high-order bits of the more-specific prefix and
   the high-order bits of the aggregate are the same.  The number of
   bits tested is the mask-length of the aggregate.




Brim, et al.            Expires January 17, 2008               [Page 10]


Internet-Draft                  LISP-CONS                      July 2007


   When a more-specific prefix is added to the EID-prefix table, the
   corresponding aggregate is sent in a Push-Add message from a child
   peer to a parent peer in a different level.

   Push-Add messages contain an EID-prefix, and Originator Address, a
   64-bit sequence number, and a PV that records the path the message
   took in the CDR level (Section 6.3).  Note that the Originator
   Address is an EID used to route a Reply back to the requesting ITR
   The PV list will always contain Locators.

   When a CDR receives a Push-Add message, it first checks to see if the
   sequence number for the EID-prefix is numerically larger than what it
   has stored for the EID-prefix.  If it is not, the message is dropped.
   Otherwise, the CDR next checks for its own address in the PV.  If it
   exists, the message is discarded.  Otherwise, the CDR stores EID-
   prefix and the associated PV.  Note that the CDR can store all
   different combination of PVs or just the shortest path ones.  If the
   CDR has one or more parent peerings configured (i.e., the CDR is a
   child), it will aggregate this EID-prefix with other EID-prefixes
   into a more coarse EID-prefix.  The CDR does not need to advertise
   anything to lower-level CDRs because child peers will auto-generate a
   default EID-prefix into their level simply due to having a child-
   parent peering relationship.

   When a CDR sends a Push-Add message to a parent, the stored PV is not
   propagated to the parent in the aggregated EID-prefix; rather, it
   includes a one element PV which contains the address of the CDR
   originating the "aggregated push".  It also includes a new sequence
   number, indicating that this is a different EID-prefix than the ones
   it has stored.

   Finally, if a CDR is a child, it pushes a "EID-default" to its
   siblings.  This Push message has EID-prefix 0.0.0.0/0 or 0::0/0 and a
   PV containing the address of the CDR that is sourcing the default.

5.2.  Querying the LISP-CONS Database

   Map Requests are routed along the LISP-CONS multi-level topology from
   requesting ITR to rCAR holding the requested mapping.  The Map-
   Request message includes a PV which records the route traversed by
   the Map-Request message.  This PV is used to control request routing
   and for debugging purposes.

   When an ITR wants to query the LISP-CONS database for a mapping, it
   prepares a Map-Request message, which is sent to one of its directly
   connected qCAR(s).  The Map-Request message is routed over the
   peering topology to the rCAR that holds the mapping.  If the qCAR has
   cached the mapping (perhaps from a previous request), in which case



Brim, et al.            Expires January 17, 2008               [Page 11]


Internet-Draft                  LISP-CONS                      July 2007


   it returns the mapping immediately.

   When a qCAR receives a Map-Request from from an ITR, it MAY respond
   immediately if it has the cached requested mapping.  Otherwise, it
   MUST forward the Map-Request message to its parent CDRs.  This CAR is
   identified by the Originator address in the Map-Request message
   (Section 6.3).  The Originator address allows a replying CDR to
   forward a Unreachable message (Section 6.5) back to the qCAR.  This
   case arises when source-site is LISP-enabled (i.e., there is an ITR
   deployed), but the destination-site has not deployed LISP yet so
   there is no ETR.

   When a Map-Request arrives at a CDR, the CDR first scans its PV for
   its address.  If its address is present, it drops the packet.  If its
   address is not present, it consults its EID-prefix table for the
   longest match "next-hop" towards the rCAR holding the mapping for the
   prefix.  If a next-hop is found, the CDR appends its address to the
   PV, and forwards the Request to the next-hop.

   When a Map-Request arrives at a CDR which cannot route it, a LISP-
   CONS Unreachable message (Section 6.5) MUST BE sent back to the qCAR.
   This Unreachable message is a signal that indicates that there is no
   mapping for the requested EID in the system, and is immediately
   communicated to the ITR.

   When a Map-Request message arrives at a rCAR, it first queries its
   mapping database for the EID contained in the Map-Request message.
   If the mapping is found, it constructs a Map-Reply message
   (Section 6.4) containing the EID, the corresponding RLOC-set, and an
   PV containing its address appended to the reverse of the received PV.
   The CAR then sends the Map-Reply message over the peering topology to
   the qCAR (i.e., to the Originating CAR EID-Prefix in the Map-Request
   message).

   If no mapping is found, the rCAR sends a Map-Reply with the requested
   EID and a Locator count of 0 back to qCAR.  This creates a negative
   cache entry in the requesting ITR.

   In LISP-CONS, the PV for Map-Request and Map-Reply messages are
   preserved across the hierarchy, while the PV lists carried in Push-
   Add and Push-Delete messages are not.  As a result, LISP-CONS also
   has cross-level loop suppression.

5.3.  Maintaining the LISP-CONS Database

   While LISP-CONS is not a routing protocol (and as such when peering
   connections go down EID-prefix entries are not immediately withdrawn
   from the local EID-prefix table), it does uses a link-state-like



Brim, et al.            Expires January 17, 2008               [Page 12]


Internet-Draft                  LISP-CONS                      July 2007


   sequence number scheme to detect changes in topology.  Similarly,
   LISP-CONS uses a path vector scheme to detect and suppress message
   looping.  There are four database maintenance cases to consider:

   o  An EID-Prefix Is Administratively Removed From The Infrastructure
      (Section 5.3.1)

   o  A CAR's Connectivity Changes (Section 5.3.2)

   o  A CAR Becomes Unreachable (Section 5.3.3)

   o  A CDR Becomes Unreachable (Section 5.3.4)

   Each case is considered below.

5.3.1.  An EID-Prefix Is Administratively Removed From The
        Infrastructure

   EID-prefix mappings are removed from the LISP-CONS infrastructure by
   administrative configuration at the rCAR that was configured with the
   mapping.  The CAR queries its EID-prefix database for the mapping.
   If no match for the EID-prefix exists, no further action is taken.

   When all the more-specific prefixes that matches the aggregate are
   removed from the EID-prefix table, the aggregate is sent in a Push-
   Delete message from a child peer to a parent peer in a different
   level.  The Push-Delete message behaves exactly like the Push-Add
   message, except that it removes the corresponding state along its
   path(s).

   When a Push-Delete message arrives at a CDR, the CDR checks for its
   own address in the PV.  If it exists, the message is discarded.
   Otherwise, the CDR queries its EID-prefix database for the EID-prefix
   in the received Push-Delete message.  If it finds a matching entry,
   it removes the entry from its database, appends its address to the
   PV, and forwards the message to its siblings.

   If the CDR is a child, it checks to see if the EID-prefix in the
   Push-Delete message is the last in an aggregate it had previously
   pushed to its parent CDR.  If not, no further action is taken.
   Otherwise, the CDR computes a new aggregate (minus the prefix from
   the Push-Delete), sends a Push-Delete for the old aggregate to its
   parent, and sends a Push-Add with the new aggregate to its parent
   CDR.







Brim, et al.            Expires January 17, 2008               [Page 13]


Internet-Draft                  LISP-CONS                      July 2007


5.3.2.  A CAR's Connectivity Changes

   Changes in CAR connectivity are signaled by changes in the sequence
   numbers in a Push-Add messages.  For example, in Figure 3, consider
   the case in which the D<->B TCP connection breaks.  In this case, D
   sends a Push-Add with EID-Prefix EID/(n-1), sequence number, S+1, and
   path vector [D] (denoted push(EID/(n-1), S+1, [D])) to C. C
   aggregates the pieces of EID and forwards push(EID/n,S+1,[C,D]) to B.
   Now, before the failure, B had an entry in its EID-prefix table for
   EID/n with sequence number S and PV [D].  Since B sees a new push
   message originated by D with sequence number S+1, it knows the
   previous entry (EID/n,S,[D]) is no longer valid.

   Similarly, A will see push messages with both [C,D] and [B,C,D] and
   with sequence number S+1, so it knows the existing entries ([B,D] and
   [C,B,D], with sequence number S) are both obsolete.

                                      A
                                   /     \
                          ^       /       \       ^
                          |      /         \      |
    push(EID/n,S,[B,C,D]) |     /           \     | push(EID/n,S,[C,D])
                               /    CDR      \
    push(EID/n,S,[A,C,D]) |   /     mesh      \   | push(EID/n,S,[A,B,C,D])
                         \|/ /                 \ \|/ (will be discarded)
                            /                   \
                           /                     \
                          B-----------------------C
                           \ push(EID/n,S,[C,D]) /
                         ^  \    <---------     / ^
                         |   \                 /  |
      push(EID/n,S,[D])  |    \               /   | push(EID/n,S,[D])
                         |     \             /    |
                                \           /
                                 \         /
                                   D (CAR)   Configure EID/(n-1), RLOC-set
                                      |
                                      |
                                      |
                                      |
                                      |
                                    F (ETR)


                   Figure 3: Sequence Number Processing






Brim, et al.            Expires January 17, 2008               [Page 14]


Internet-Draft                  LISP-CONS                      July 2007


5.3.3.  A CAR Becomes Unreachable

   If the TCP connection between a CAR its peer CDR drops, a timer
   associated with the EID-prefix received from the CAR in the Push-Add
   message is started.  The timer, called the CAR-CDR-TCP-TIMER, is set
   to a default value of 60 minutes.

   If the TCP connection comes back up before the timer expires, the
   timer is stopped and no further action is taken.

   If the timer expires, the CDR builds a Push-Delete message for each
   EID-prefix it received from the rCAR, and sends the Push-Delete to
   its siblings.  The Push-Delete message contains the EID-prefix to be
   removed, a sequence number, and PV containing only the CDR's address.

   If the CDR also has a parent peering, it checks to see if any of the
   EID-prefixes it received from a child peering were the last more
   specific prefix in an aggregate it previously pushed to a parent CDR.
   If not, no further action is taken.  If so, it sends a Push-Delete
   for the aggregate to its parent(s).  In either case, the CDR deletes
   the entries received from the failed CAR from its EID-prefix table.

5.3.4.  A CDR Becomes Unreachable

   There are three cases to consider here: A sibling CDR peering goes
   down, a parent peering goes down, and an child peering goes down.
   Each is considered below.

5.3.4.1.  A Sibling CDR Becomes Unreachable

   When the TCP connection drops between a CDR and a sibling CDR, a
   timer associated with the EID-prefixes received from the sibling CDR
   in the Push-Add message is started.  This timer, called CDR-SIBLING-
   TCP-TIMER, defaults to TBD.

   If the TCP connection comes back up before the timer expires, the
   timer is stopped and no further action is taken.

   If the timer expires, the CDR builds a Push-Delete message for each
   EID-prefix it received from the CDR, and sends the Push-Delete to its
   siblings.  The Push-Delete message contains the EID-prefix to be
   removed, a sequence number, and PV containing only the CDR's address.

   If the CDR also has a parent peering, it checks to see if any of the
   EID-prefixes it received from the failed CDR were the last more
   specific prefix in an aggregate it previously pushed to a parent CDR.
   If not, no further action is taken.  If so, it sends a Push-Delete
   for the aggregate to its parent(s).  In either case, the CDR deletes



Brim, et al.            Expires January 17, 2008               [Page 15]


Internet-Draft                  LISP-CONS                      July 2007


   the entries from its EID-prefix table.

5.3.4.2.  A Parent CDR Becomes Unreachable

   When the TCP connection drops between a CDR and a parent CDR, the
   child starts a timer (the CDR-CDR-TCP-TIMER) associated with the
   parent CDR.

   If the TCP connection comes back up before the timer expires, the
   timer is stopped and no further action is taken.

   If the timer expires, the CDR deletes the EID-prefix entry, and
   builds a Push-Delete message for the default EID prefix and sends it
   to its siblings.  The Push-Delete message contains the EID-prefix
   0.0.0.0/0 or 0::0/0, a sequence number, and PV containing only the
   CDR's address.

5.3.4.3.  A Child CDR Becomes Unreachable

   Since nothing is ever "pushed down", no action needs to be taken when
   a child CDR becomes unreachable.  See Section 5.3.4.2 for the actions
   a child CDR takes when a parent becomes unreachable.


6.  LISP-CONS Message Types

   LISP messages are sent over either UDP or TCP sockets using well-
   known IANA-assigned port number 4342.

   In all message formats, IPv4 or IPv6 addresses can be mixed or match.
   So a payload of IPv6 addresses can be sent over a TCP connection (or
   be UDP encapsulated) that runs over IPv4 and vice-versa.  You can
   also mix EID-to-RLOC mappings.  That is, an IPv6 EID-prefix can have
   a set of IPv4 or IPv6 Locator addresses associated with it and vice-
   versa.  Originator addresses and Path Vector lists can also be mixed
   as well.

   A TCP connection is established by two LISP-CONS peers by having the
   higher IP address side of the connection do a passive-open and the
   lower IP address side to an active open.  This is done to avoid 2
   connections from call colliding.  This is similar to the procedures
   in [RFC3618].

6.1.  Open Message

   This is the first message sent when a TCP connection is established
   between ITR-to-qCAR, CAR-to-CDR, or CDR-to-CDR peering relationships.
   The main purpose for the Open message is to determine the peering



Brim, et al.            Expires January 17, 2008               [Page 16]


Internet-Draft                  LISP-CONS                      July 2007


   relationship and level number between the two LISP neighbors.  Other
   purposes are for capability negotiation and for sending keep-alives.

   Open messages MUST be sent over a TCP connection, and a LISP-CONS
   peer MUST NOT accept any LISP packet type before an Open message is
   received.

   Open Message format


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      / | Type  |P|C|S|   Rsvd  | Level |          Checksum             |
     /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP    |                     TLV Encodings                             |
     \  |                                                               |
      \ |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   Type:  4

   P: When set to 1, the local LISP peer is acting as a parent for the
      peering connection.  When acting as a parent connection, the
      system is performing CDR functionality.  It should not accept any
      peering connections other than from a child peer.

   C: When set to 1, the local LISP peer is acting as a child for the
      peering connection.  When acting as a child connection, the system
      is performing CDR functionality and pushes the default EID-prefix
      0.0.0.0/0 or 0::/0 into the CDR mesh it is part of.  It should not
      accept any peering connections other than from a parent peer.

   S: When set to 1, the local LISP peer is acting as a sibling for the
      peering connection.  When acting as a sibling connection, the
      system is performing CDR functionality.  The two peers are in the
      same CDR mesh-level.  It should not accept any peering connections
      other than from a sibling peer.

      When all of P, C, and S bits are cleared, the system is acting as
      a CAR.  A CAR peering relationship with a CDR is like a CDR-child
      to CDR-parent peering relationship with the exception the CAR
      doesn't push any default EID-prefixes because CARs do not create
      meshes.  They simply push aggregate EID-prefixes from mapping
      entries.






Brim, et al.            Expires January 17, 2008               [Page 17]


Internet-Draft                  LISP-CONS                      July 2007


      Note also that that 2 or more of the P, C, and S bits cannot be
      set.  If they are, the other side SHOULD NOT accept the
      connection.

   Rsvd:  Set to 0 on transmission and ignore on receipt.

   Level:  The level number used for peering.  When a sibling peering
      relationship is configured, the level numbers must be the same.
      When there is a child-to-parent peering relationship, the parent's
      level number MUST BE greater than the child's announced level
      number.  The CARs are at level 0, and the next level (upwards)
      could be any level greater than 0.

   Checksum:  A complement of the 1-complements sum of the LISP packet.
      The checksum is always required for an Open message.

   TLV Encodings  If the LISP Open message is greater than 4 bytes in
      length, then enclosed are Type-Length-Value encodings in the
      format of:

      TLV Encodings

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type               |          TLV  Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Value                             |
     |                               .                               |
     |                               .                               |
     |                               .                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                   Figure 5

   Type:  2-byte Type value for a TLV in an Open message.

   TLV Length:  2-byte length value, in bytes, of the entire TLV
      including the Type and TLV Length fields.  A value less than 4 is
      illegal.

   Value:  Value: The data for the defined Type value.  The format is
      Type-specific and can be defined and documented in other
      specifications.








Brim, et al.            Expires January 17, 2008               [Page 18]


Internet-Draft                  LISP-CONS                      July 2007


6.2.  Push-Add and Push-Delete

   A Push-Add message is sent by a rCARs to its parent CDR(s), from a
   sibling CDR to another sibling CDR, and from a child CDR to a parent
   CDR.  Push messages, in general are always sent up and horizontally
   in the LISP-CONS hierarchical topology and never sent down.

   A Push-Delete message is sent by a rCAR to its parent CDR(s), from a
   sibling CDR to another sibling CDR, and from a child CDR to a parent
   CDR.  Push messages, in general are always sent up and horizontally
   in the LISP-CONS hierarchical topology and never sent down.  A Push-
   Delete message is used to undo what a Push-Add installed.

   Push Message Format


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type  |       Reserved        |         Checksum              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | EID mask-len  |    EID-AFI    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Sequence  Number ...                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    ... Sequence  Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         EID-prefix ...                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Path Vector  List                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 6

   Type:  5 is a Push-Add and 6 is a Push-Delete

   Reserved:  Set to 0 on transmission and ignored on receipt.

   Checksum:  A complement of the 1-complements sum of the LISP packet.
      The checksum is always required for a Push message.

   EID mask-len:  Mask length for EID prefix.

   EID-AFI:  Address family of the EID-prefix.

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.





Brim, et al.            Expires January 17, 2008               [Page 19]


Internet-Draft                  LISP-CONS                      July 2007


   Path Vector List:  A list of CDRs that have accepted, stored and
      forwarded this message.  The format is:

      Path Vector List

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     AFI       |   Locator Router-ID  Address ...              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                   Figure 7

   AFI:  Address family of entry in Path Vector List.

   Locator Router-ID Address:  4 bytes if an IPv4 address-family, 16
      bytes if an IPv6 address-family.  Note that the first entry in the
      Path Vector List is the Originator of the Push message.

6.3.  Map-Request Message

   A Map-Request message is used to retrieve an EID-to-RLOC mapping
   based on a requested EID or EID-prefix in this Request message.  This
   message can be sent over TCP connection or be a UDP encapsulated.

   Map-Requests are originated by ITRs at LISP sites to retrieve a
   mapping they do not have cached.  A qCAR will reformat the mapping
   and forward it upward along the LISP-CONS hierarchical tree topology.
   The authoritative text for the format of this message is found in
   [LISP-02].























Brim, et al.            Expires January 17, 2008               [Page 20]


Internet-Draft                  LISP-CONS                      July 2007


   Map-Request Message Format

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type  |  Locator Reach Bits   |         Checksum              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Nonce ...                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          ... Nonce            | Record count  |A|   Reserved  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           ITR-AFI             |            CAR-AFI            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Originating ITR RLOC Address                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Originating CAR EID-Prefix                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Rec -> | EID mask-len  |    EID-AFI    |          EID-prefix ...       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Path Vector List                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 8

   Type:  2

   Locator Reach Bits:  These bits are set by an ITR to indicate to an
      ETR the reachability of the Locators in the source site.  Each
      RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1
      (when there are n RLOCs in a mapping entry).  The Locator Reach
      Bits are number from 0 to n-1 from the right significant bit of
      the 12-bit field.  When a bit is set to 1, the ITR is indicating
      to the ETR the RLOC associated with the bit ordinal is reachable.
      See [LISP-02] for details on how an ITR can determine other site
      ITRs are reachable.

   Checksum:  A complement of the 1-complements sum of the LISP packet.
      The checksum is always required for Map-Requests sent over TCP
      connections.  For UDP encapsulated Map-Requests, either this
      checksum can be used or the UDP checksum field can be used but not
      both, one of them must be non-zero and the other set to 0.

   Nonce:  A 6-byte random value created by the sender of the Map-
      Request.

   Record count:  The number of records in this request message.  A
      record comprises of what is labeled 'Rec" above and occurs the a
      number of times equal to Record count.





Brim, et al.            Expires January 17, 2008               [Page 21]


Internet-Draft                  LISP-CONS                      July 2007


   A: This is an authoritative bit, where when a request has this bit
      set any intermediate LISP peers that have a mapping cached, will
      not return the mapping but allow the request to travel to the
      authoritative rCAR.  That is, the one with the configured mapping.
      This is necessary so an ITR or qCAR attached to an ITR can get the
      most up to date information about a locator-set that may have
      changed.

   ITR-AFI:  Address family of the "Originating ITR RLOC Address" field.

   CAR-AFI:  Address family of the "Originating CAR EID-prefix" field.

   Originating ITR RLOC Address:  For TCP-based Map-Requests, the qCAR
      that peers with the ITR will fill in this address.  This address
      is the same address the CAR uses to peer with the ITR.  This
      address is copied by the replying CAR to the Map-Reply, so a
      requesting CAR knows which ITR made the request.

   Originating CAR EID-Prefix:  For TCP-based Map-Requests, the qCAR
      fills in this prefix so a Reply can be routed back to the
      requesting CAR over the CONS topology.  This prefix can be any
      prefix the CAR is aggregating up to a parent CDR.

   EID mask-len:  Mask length for EID prefix.

   EID-AFI:  Address family of EID-prefix according to [RFC2434].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Path Vector List:  Contains a list of CDRs this Request has
      traversed.  Each CDR appends its address to the message and
      recalculates the checksum.  The format is the same as the format
      of the Push Message.  If the length of the packet is greater than
      the length to include the EID-records, then the PV list is
      present.  Otherwise, there is no PV list.

6.4.  Map-Reply Message

   A Map-Reply message is used to return an EID-to-RLOC mapping.  This
   message can be sent over TCP connection or may be a UDP encapsulated.
   When the message is data triggered, it is sent over UDP.  See
   [LISP-02] for details.  When the message is sent in response to a
   received Map-Request over TCP, the reply is returned over TCP
   according to this LISP-CONS specification.

   A Map-Reply is originated by a rCAR when a request is received for an
   EID or EID-prefix for which it has an authoritative mapping for.



Brim, et al.            Expires January 17, 2008               [Page 22]


Internet-Draft                  LISP-CONS                      July 2007


   That is, a mapping for site that has been allocated the EID-prefix
   and who has informed the CAR of the ETR Locator addresses.

   The authoritative text for the format of this message can be found in
   [LISP-02].

   Map-Reply Message Format


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type  |  Locator Reach Bits   |         Checksum              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Nonce ...                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          ... Nonce            | Record count  |   Reserved    |
 +----> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      |                          Record  TTL                          |
 |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      | Locator count | EID mask-len  |A|        Reserved             |
 |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 R      |           ITR-AFI             |            EID-AFI            |
 e      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 c      |                   Originating ITR RLOC Address                |
 o      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 r      |                          EID-prefix                           |
 d      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     /|    Priority   |    Weight     |    Unused     |    Loc-AFI    |
 |  Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     \|                             Locator                           |
 +--->  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Path Vector List                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 9

   Type:  3

   Locator Reach Bits:  These bits are set by an ITR to indicate to an
      ETR the reachability of the Locators in the source site.  Each
      RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1
      (when there are n RLOCs in a mapping entry).  The Locator Reach
      Bits are number from 0 to n-1 from the right significant bit of
      the 12-bit field.  When a bit is set to 1, the ITR is indicating
      to the ETR the RLOC associated with the bit ordinal is reachable.
      See [LISP-02] for details on how an ITR can determine other site
      ITRs are reachable.





Brim, et al.            Expires January 17, 2008               [Page 23]


Internet-Draft                  LISP-CONS                      July 2007


   Checksum:  A complement of the 1-complements sum of the LISP packet.
      The checksum can be set to 0 and not computed on receipt when
      encapsulated in UDP.  In this case, the UDP checksum is required
      to be computed.  The LISP checksum is required to be computed and
      checked when this message is sent over a TCP connection.

   Nonce:  A 6-byte value which was either in a Map-Request message that
      invoked this reply or in a data triggered LISP encapsulated packet
      (i.e. a Data message).

   Record count:  The number of records in the message.  The record
      comprises what is labeled 'Record' above.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry should be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc".

   EID mask-len:  Mask length for EID prefix.

   A: The Authoritative bit, when this is set, the reply is from a rCAR
      where the mapping is configured.  If any LISP-CONS peer is
      replying on behalf of a CAR because it has cached a mapping (to
      reduce lookup latency), the A bit should be set to 0.

   ITR-AFI:  Address family of the "Originating ITR RLOC Address" field.

   EID-AFI:  Address family of EID-prefix according to [RFC2434].

   Originating ITR RLOC Address:  For TCP-based Map-Replies, the rCAR
      copies the "Originating ITR RLOC Address" from the Map-Request to
      this field.  This aids the qCAR to know which ITR sent the
      request.

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority, Weight, Unused, Loc-AFI, Locator:  See [LISP-02] for
      details.  Oh, so it's just like a Blackberry.

   Locator:  The Locator used to reach the EID-prefixes in record.







Brim, et al.            Expires January 17, 2008               [Page 24]


Internet-Draft                  LISP-CONS                      July 2007


   Path Vector List:  Contains a list of CDRs this Request has
      traversed.  Each CDR appends its address to the message and
      recalculates the checksum.  The format is the same as the format
      of the Push Message.  If the length of the packet is greater than
      the length to include the EID-records, then the PV list is
      present.  Otherwise, there is no PV list.

6.5.  Unreachable Message

   Unreachable Message Format

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type  | Code  | ASCII Length  |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Unreachable TTL                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Message in ASCII...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Invoking Map-Request Message                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 10

   Type:  7

   Code:  1, when a qCAR or CDR needs to forward a Request to a next-hop
      it has previously computed but the TCP connection is not up (i.e.,
      Topology not Reachable)

   Code:  2, when a rCAR receives a Map-Request forwarded from a CDR and
      there is no mapping for the EID-prefix (i.e.  Not Found).

   Code:  3, when a Request or a Reply was found to loop when
      manipulating the Path Vector list.

   ASCII length:  The number of bytes (including the null terminated
      character) the for optional ASCII message appended.  When set to
      0, there is no ASCII string present in the message.

   Checksum:  A complement of the 1-complements sum of the LISP packet.
      The checksum is always required for an Open message.

   Unreachable TTL:  The time in minutes the recipient of the
      Unreachable message MAY cache the mapping with an empty Locator-
      set.  If the TTL is 0, there should be no caching of this state.
      If the value is 0xffffffff, the recipient MAY decide locally how
      long to store the mapping.




Brim, et al.            Expires January 17, 2008               [Page 25]


Internet-Draft                  LISP-CONS                      July 2007


   Message in ASCII:  An ASCII encoded string with a null terminated
      byte.  The string can be configured on a CAR and display on the
      qCAR.

      The last part of the Unreachable contains the entire Map-Request
      message which invoked the Unreachable message.


7.  Operational Considerations

   TBD: However, mention that there will be less policy than in BGP.
   That is, information cannot be altered, like a CAR cannot add or
   remove locators, path-vectors can't be made to look longer, etc....

   Future revisions of this document will have a more through
   description of deployment scenarios, once we get some implementation
   and pilot deployment experience.


8.  LISP-CONS and Locator Reachability

   It is important to note that LISP-CONS is designed to as a mapping
   database that defines EID-to-RLOC mappings, where the RLOCs are IP
   addresses of ETRs and does not indicate if the ETRs, or the path to
   the ETRs are up.

   In general, LISP determine reachability through either ICMP
   Unreachable messages or LISP data-plane Locator Reach bits that are
   transmitted in LISP Data messages [LISP-02].

   The design principle underlying LISP-CONS is to keep the mapping
   database service scalable.  As such, the design discourages high
   frequency changes in mappings.


9.  LISP-CONS and Mobility

   The mapping database does not convey Foreign Agent locator addresses.
   This can be achieved in the data plane but will be documented in
   another Internet Draft.


10.  Open Issues

   o  Do we need a Close Message? (dual of open).Otherwise EID-prefixes
      may not get removed until a timeout.





Brim, et al.            Expires January 17, 2008               [Page 26]


Internet-Draft                  LISP-CONS                      July 2007


   o  No mapping exists in the ITR: You have a configuration option to
      either 1) drop the packet, or 2) do LISP 1.5 where the packet is
      routed on another topology.  The other option is to allow the ITR
      get a push of 0.0.0.0/0 or 0::0/0 from its peering CARs (or have
      it configured in the ITR).

   o  Security Section: We need to finish the evaluation of
      vulnerabilities.  Map vulnerabilities against security mechanisms.
      At first blush, the real outstanding question remaining (as you
      note in your notes above) is transitive message security (ala dns-
      sec).

   o  Security Model: Is the implied transitive trust sufficient?


11.  Acknowledgments

   Many of the ideas described in this document developed during
   detailed discussions with Noel Chiappa, Eliot Lear, Mark Handley, and
   Dave Oran.  Robin Whittle also made several insightful comments on
   earlier versions of this document.


12.  Security Considerations

   LISP-CONS is a straightforward protocol to secure.  Its combination
   of simplicity, explicit peering, and explicit configuration provides
   for a well understood set of relationships between elements.  Its
   security mechanisms are comprised of existing technologies in wide
   operational use today.

   As a hybrid push-pull protocol, LISP-CONS shares some of security
   characteristics of pull (DNS) and push (BGP) protocols.  Securing
   LISP-CONS is much simpler than either of those examples however.
   Compared to DNS, the fact that messages traverse a explicit hierarchy
   of TCP connections, and the message make-up itself makes LISP-CONS
   less susceptible to denial of service and amplification attacks.
   Compared to BGP, LISP-CONS CDRs are not topologically bound, allowing
   them to be put in locations away from the vulnerable AS border
   (unlike eBGP speakers).

12.1.  Apparent LISP-CONS Vunerabilities

   This section briefly lists of the apparent vulnerabilities of LISP-
   CONS.






Brim, et al.            Expires January 17, 2008               [Page 27]


Internet-Draft                  LISP-CONS                      July 2007


   Mapping Integrity:  Can you insert bogus mappings to black-hole
      (create a DoS) or intercept LISP data-plane packets?

   CAR Availability:  Can you DoS the rCAR(s) holding the mappings for a
      particular ETR?  Without access to its 1-2 available CAR(s) an ITR
      has no ability to connect to the rest of the Internet.

   ITR Mapping/Resources:  Can you force an ITR to drop legitimate
      mapping requests by flooding it with random destinations that it
      will have to query for?  Seems like a problem with any pull based
      system (DNS has this problem).  Is this an ITR implementation
      issue, or is there a way we can assist ITR implementers here in
      the LISP-CONS spec?

   Path Vector Exploits for Reconnaissance:  Can you learn about the
      LISP topology by sending legitimate mapping requests messages and
      then observing the path-vector information.  Is this information
      useful in attacking or subverting peer relationships?  Not data
      plane but control plane service - this vulnerability seems unique
      to LISP-CONS.  ITRs cannot do this, since they don't have access
      to the PVs (the PVs aren't sent along to the ITRs).  Note that
      LISP has a similar data-plane reconnaissance issue.

   Scaling of CAR/CDR Resources:  Can you flood the system with requests
      or replies due to the limited capacity of the control plane?  TCP
      prevents anycasting to add capacity, and one of the issues has to
      be how do we scale if we need to?

12.2.  Survey of LISP-CONS Security Mechanisms

   Use of Device Loopbacks:  From levels 0 to 1 (or n) in the topology,
      these loopbacks should come from known infrastructure subnets (as
      do say BGP peers) that should allow for some isolation via Access
      Control Lists (ACLs) and anti-spoofing mechanisms.

   Explicit Peering:  The devices themselves can both prioritize
      incoming packets as well as potentially do key checks in hardware
      to protect the control plane.

   Use of TCP to Connect Loopbacks:  This makes it difficult for third
      parties to inject packets.

   Use of HMAC Protected TCP Connections:  HMAC is used to verify
      message integrity and authenticity, making it nearly impossible
      for third party devices to either insert or modify messages.






Brim, et al.            Expires January 17, 2008               [Page 28]


Internet-Draft                  LISP-CONS                      July 2007


   Message Sequence Numbers and Nonce Values in Messages:  This allows
      for devices to verify that the mapping-reply packet was in
      response to the mapping-request that they sent.

   Path Vectors:  Path Vectors prevent arbitrary messages from
      traversing the topology, and raise the bar for spoofing/invalid
      Path-Delete messages.


13.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].


14.  References

14.1.  Normative References

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

   [LISP-02]  Farinacci, D., Fuller, V., Oran, D., and D. Meyer,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-02 (work in progress), July 2007.

14.2.  Informative References

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [I-D.iab-raws-report]
              Meyer, D., "Report from the IAB Workshop on Routing and
              Addressing", draft-iab-raws-report-02 (work in progress),
              April 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed



Brim, et al.            Expires January 17, 2008               [Page 29]


Internet-Draft                  LISP-CONS                      July 2007


              Enhancement to the Internet Architecture", Internet
              Draft, http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.


Authors' Addresses

   Scott Brim

   Email: sbrim@cisco.com


   Noel Chiappa

   Email: jnc@mercury.lcs.mit.edu


   Dino Farinacci

   Email: dino@cisco.com


   Vince Fuller

   Email: vaf@cisco.com


   Darrel Lewis

   Email: darlewis@cisco.com


   David Meyer

   Email: dmm@cisco.com
















Brim, et al.            Expires January 17, 2008               [Page 30]


Internet-Draft                  LISP-CONS                      July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Brim, et al.            Expires January 17, 2008               [Page 31]


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