Network Working Group                                           D. Lewis
Internet-Draft                                                  D. Meyer
Intended status: Experimental                               D. Farinacci
Expires: August 20, September 1, 2012                                     V. Fuller
                                                     Cisco Systems, Inc.
                                                       February 17, 29, 2012

                  Interworking LISP with IPv4 and IPv6
                  draft-ietf-lisp-interworking-04.txt
                  draft-ietf-lisp-interworking-05.txt

Abstract

   This document describes techniques for allowing sites running the
   Locator/ID Separation Protocol (LISP) to interoperate with Internet
   sites (which may be using either IPv4, IPv6, or both) but which are
   not running LISP.  A fundamental property of LISP speaking sites is
   that they use Endpoint Identifiers (EIDs), rather than traditional IP
   addresses, in the source and destination fields of all traffic they
   emit or receive.  While EIDs are syntactically identical to IPv4 or
   IPv6 addresses, normally routes to them are not carried in the global
   routing system so an interoperability mechanism is needed for non-
   LISP-speaking sites to exchange traffic with LISP-speaking sites.
   This document introduces three such mechanisms.  The first uses a new
   network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Proxy-ITRs)
   (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
   for non-LISP-speaking hosts.  Second the document adds Network
   Address Translation (NAT) functionality to LISP Ingress and LISP
   Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
   non-routable EIDs.  Finally, this document introduces a the Proxy
   Egress Tunnel Router (PETR) (Proxy ETR) to handle cases where a LISP ITR
   cannot send packets to non-LISP sites without encapsulation.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."
   This Internet-Draft will expire on August 20, September 1, 2012.

Copyright Notice

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  LISP Interworking Models  Definition of Terms  . . . . . . . . . . . . . . . . . . .  6
   3.  Definition of Terms . .  6
   3.  LISP Interworking Models . . . . . . . . . . . . . . . . . . .  7
   4.  Routable EIDs  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Impact on Routing Table  . . . . . . . . . . . . . . . . .  8
     4.2.  Requirement for using sites to use BGP . . . . . . . . . . . . . . . .  8
     4.3.  Limiting the Impact of Routable EIDs . . . . . . . . . . .  8
     4.4.  Use of Routable EIDs for sites transitioning to LISP . . .  8
   5.  Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
     5.1.  PITR  Proxy-ITR EID announcements  . . . . . . . . . . . . . . . . . . 10
     5.2.  Packet Flow with PITRs . . . Proxy-ITRs  . . . . . . . . . . . . . . . 10
     5.3.  Scaling PITRs  . . Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Impact of the PITRs Proxy-ITRs placement in the network  . . . . . . . 12
     5.5.  Benefit to Networks Deploying PITRs  . . Proxy-ITRs . . . . . . . . . 12
   6.  Proxy Egress Tunnel Routers  . . . . . . . . . . . . . . . . . 13
     6.1.  Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13
   7.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1. 15
     7.1.  Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13
     6.2. 15
     7.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending
           to non-LISP Sites  . . . . . . . . . . . . . . . . . . . . 14
     6.3. 16
     7.3.  LISP Sites with Hosts using RFC 1918 Addresses
           Sending Packets to Other LISP Sites  . . . . . . . . . . . 14
     6.4. 16
     7.4.  LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15
   7.  Proxy Egress Tunnel Routers  . . . . . . . . . . . . . . . . . 16
     7.1.  Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16 17
   8.  Discussion of Proxy ITRs (PITRs), Proxy-ITRs (Proxy-ITRs), LISP-NAT, and
       Proxy-ETRs
       (PETRs)  . . . . . . . . (Proxy-ETRs)  . . . . . . . . . . . . . . . . . . . 18
     8.1.  How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

1.  Introduction

   This document describes interoperation mechanisms between LISP [LISP]
   sites which use non-globally-routed EIDs, and non-LISP sites.  The first is
   the use of Proxy Ingress Tunnel router (PITRs), which originate
   highly-aggregated routes to EID prefixes for non-LISP sites to use.
   It also describes the use of NAT by LISP ITRs when sending packets to
   non-LISP hosts.  Finally, it describes Proxy Egress Tunnel routers
   (PETRs) LISP for sites relying on PITRs, and which are faced with
   certain restrictions.  A key
   behavior of the separation of Locators and End-Point-IDs Endpoint IDs is that EID
   prefixes are normally not advertised into the Internet's Default Free
   Zone (DFZ).  Specifically, only Routing Locators (RLOCs) are carried
   in the Internet's DFZ.  Existing Internet sites (and their hosts)
   which do not run in the LISP protocol must still be able to reach
   sites numbered from LISP EID space.  This draft describes three
   mechanisms that can be used to provide reachability between sites
   that are LISP-capable and those that are not.

   The first mechanism uses a new network element, the LISP Proxy
   Ingress Tunnel Router (PITR) (Proxy-ITR) to act as a intermediate LISP
   Ingress Tunnel Router (ITR) for non-LISP-speaking hosts.  The second
   mechanism adds a form of Network Address Translation (NAT)
   functionality to Tunnel Routers (xTRs), to substitute routable IP
   addresses for non-routable EIDs.  The final network element is the
   LISP Proxy Egress Tunnel Routers (PETR), (Proxy-ETR), which act as an
   intermediate Egress Tunnel Router (ETR) for LISP sites which need to
   encapsulate
   packets LISP packets destined to non-LISP sites.

   More detailed descriptions of these mechanisms and the network
   elements involved may be found in the following sections:

   - Section 2 defines terms used throughout the document

   - Section 2 describes the different cases where interworking
   mechanisms are needed

   - Section 3 defines terms used throughout the document

   - Section 4 describes the relationship between the new EID prefix
   space and the IP address space used by the current Internet

   - Section 5 introduces and describes the operation of Proxy-ITRs Proxy Ingress
   tunnel Routerss

   - Section 6 introduces and describes the operations of Proxy-ETRs

   - Section 7 defines how NAT is used by ETRs to translate non-routable
   EIDs into routable IP addresses.

   - Section 7 introduces and describes the operations of Proxy-ETRs
   - Section 8 describes the relationship between asymmetric and
   Symmetric
   symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
   NAT)

   Note that any successful interworking model should be independent of
   any particular EID-to-RLOC mapping algorithm.  This document does not
   comment on the value of any of the particular LISP mapping systems.

   Several areas concerning the Interworking of LISP and non-LISP sites
   remain open for further study.  These areas include an examination of
   the impact of LISP-NAT on internet Internet traffic and applications,
   understanding the deployment motivations for the deployment and
   operation of Proxy Tunnel Routers, the impact of EID routes
   originated into the Internet's Default Free Zone,and the effects of
   Proxy Tunnel Routers or LISP-NAT on internet Internet traffic and
   applications.  Until these issues are fully understood, it is
   possible that the interworking mechanisms described in this document
   are hard to deploy, or may have unintended consequences to
   applications.

2.  LISP Interworking Models

   There are 4 unicast connectivity cases which describe how sites can
   send packets  Definition of Terms

   Default Free Zone:  The Default-Free Zone (DFZ) refers to each other:

   1.  Non-LISP site the
      collection of all Internet autonomous systems that do not require
      a default route to Non-LISP site

   2.  LISP site route a packet to any destination.

   LISP site

   3. Routable (LISP-R) Site:  A LISP site to Non-LISP site

   4.  Non-LISP site to whose addresses are used as
      both globally routable IP addresses and LISP EIDs.

   LISP Non-Routable (LISP-NR) Site:  A LISP site

   Note that while Cases 3 and 4 seem similar, there whose addresses are subtle
   differences due to the way packets
      EIDs only, these EIDs are originated.

   The first case is not found in the legacy Internet as we know it today routing
      table.

   LISP Proxy Ingress Tunnel Router (Proxy-ITR):  Proxy-ITRs are used to
      provide connectivity between sites which use LISP EIDs and those
      which do not.  They act as such will gateways between those parts of the
      Internet which are not be discussed further here.  The second case is documented in
   [LISP] using LISP (the legacy Internet) A given
      Proxy-ITR advertises one or more highly aggregated EID prefixes
      into the public Internet and there are no new interworking requirements because there
   are no new protocol requirements placed on intermediate non- acts as the ITR for traffic received
      from the public Internet.  LISP
   routers.

   In case 3, Proxy-ITRs are described in
      Section 5.

   LISP site Network Address Translation (LISP-NAT):  Network Address
      Translation between EID space assigned to Non-LISP site, a LISP site can (in most
   cases) send packets and RLOC space
      also assigned to that site.  LISP Network Address Translation is
      described in Section 7.

   LISP Proxy Egress Tunnel Router (Proxy-ETR):  Proxy-ETRs provide a non-LISP site
      LISP (Routable or Non-Routable EID) site's ITRs the ability to
      send packets to non-LISP sites in cases where unencapsualted
      packets (the default mechanism) would fail to be delivered.
      Proxy-ETRs function by having an ITR encapsulate all non-LISP
      destined traffic to a pre-configured Proxy-ETR.  LISP Proxy Egress
      Tunnel Routers are described in Section 6.

    EID Sub Namespace:  A power-of-two block of aggregatable locators
      set aside for LISP interworking.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

3.  LISP Interworking Models

   There are 4 unicast connectivity cases which describe how sites can
   send packets to each other:

   1.  non-LISP site to non-LISP site

   2.  LISP site to LISP site

   3.  LISP site to non-LISP site

   4.  non-LISP site to LISP site

   Note that while Cases 3 and 4 seem similar, there are subtle
   differences due to the way packets are originated.

   The first case is the Internet as we know it today and as such will
   not be discussed further here.  The second case is documented in
   [LISP] and there are no new interworking requirements because there
   are no new protocol requirements placed on intermediate non- LISP
   routers.

   In case 3, LISP site to non-LISP site, a LISP site can (in most
   cases) send packets to a non-LISP site because the non-LISP site
   prefixes are routable.  The non-LISP site sites need not do anything new
   to receive packets.  The only action the LISP site needs to take is
   to know when not to LISP-encapsulate packets.  An ITR knows
   explicitly that the destination is non-LISP if the destination IP
   address of an IP packet matches a (negative) Map-Cache entry which
   has the action 'Natively-Forward'.

   There could be some situations where (unencapsulated) packets
   originated by a LISP site may not be forwarded to a non-LISP site.
   These cases are reviewed in section 7, (Proxy-Egress (Proxy Egress Tunnel Routers).

   Case 4, typically the most challenging, occurs when a host at a non-
   LISP site wishes to send traffic to a host at a LISP site.  If the
   source host uses a (non-globally-routable) EID as the destination IP
   address, the packet is forwarded inside the source site until it
   reaches a router which cannot forward it (due to lack of a default
   route), at which point the traffic is dropped.  For traffic not to be
   dropped, either some mechanism to make this destination EID routable
   must be in place.  Section 5 (PITRs) (Proxy-ITRs) and Section 6 (LISP-NAT)
   describe two such mechanisms.  Case 4 also applies to packets
   returning to the LISP site, in Case 3.

3.  Definition of Terms

   Default Free Zone:  The Default-Free Zone (DFZ) refers

4.  Routable EIDs

   An obvious way to the
      collection of all Internet autonomous systems that do not require
      a default route to route a packet to any destination.

   LISP Routable (LISP-R) Site:  A achieve interworking between LISP site whose addresses are used as
      both globally routable IP addresses and LISP EIDs.

   LISP Non-Routable (LISP-NR) Site:  A non-LISP
   hosts is for a LISP site whose addresses are
      EIDs only, these EIDs are not found in to simply announce EID prefixes into the legacy Internet
   DFZ, much like the current routing
      table.

   LISP Proxy Ingress Tunnel Router (PITR):  PITRs are used to provide
      interconnectivity between sites which use LISP EIDs and those
      which system, effectively treating them
   as "Provider Independent (PI)" prefixes.  Having a site do not.  They act this is
   undesirable as gateways between those parts it defeats one of the
      Internet which are not using primary goals of LISP (the legacy Internet) A given
      PITR advertises one or more highly aggregated - to
   reduce global routing system state.

4.1.  Impact on Routing Table

   If EID prefixes are announced into the public Internet and acts as DFZ, the ITR for traffic received from impact is similar to
   the public Internet.  LISP Proxy Ingress Tunnel Routers are
      described case in Section 5. which LISP Network Address Translation (LISP-NAT):  Network Address
      Translation between has not been deployed, because these EID space assigned to
   prefixes will be no more aggregatable than existing PI addresses.
   Such a mechanism is not viewed as a viable long term solution, but
   may be a viable short term way for a site and RLOC space
      also assigned to that site.  LISP Network Address Translation is
      described in Section 6.

   LISP Proxy Egress Tunnel Router (PETR):  PETRs provide transition a LISP
      (Routable or Non-Routable EID) site's ITRs the ability to send
      packets to non-LISP sites in cases where unencapsualted packets
      (the default mechanism) would fail to be delivered.  PETRs are
      function by having an ITR encapsulate all non-LISP destined
      traffic to a pre-configured PETR.  LISP Proxy Egress Tunnel
      Routers are described in Section 7.

    EID Sub Namespace:  A power-of-two block of aggregatable locators
      set aside for LISP interworking.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

4.  Routable EIDs

   An obvious way to achieve interworking between LISP and non-LISP
   hosts is for a LISP site to simply announce EID prefixes into the
   DFZ, much like the current routing system, effectively treating them
   as "Provider Independent (PI)" prefixes.  Having a site do this is
   undesirable as it defeats one of the primary goals of LISP - to
   reduce global routing system state.

4.1.  Impact on Routing Table

   If EID prefixes are announced into the DFZ, the impact is similar to
   the case in which LISP has not been deployed, because these EID
   prefixes will be no more aggregatable than existing PI addressing.
   Such a mechanism is not viewed as a viable long term solution, but
   may be a viable short term way for a site to transition a portion of
   its address space portion of
   its address space to EID space without changing its existing routing
   policy.

4.2.  Requirement for using sites to use BGP

   Non-LISP

   Routable EIDs might cause non-LISP sites today to use BGP to, among
   other things, originate their site's routes into the DFZ, and to
   enable ingress traffic engineering.  Relaxing this requirement while
   still letting sites control their ingress traffic engineering policy
   is another primary design goal of LISP.

4.3.  Limiting the Impact of Routable EIDs

   Two schemes are proposed to limit the impact of having EIDs announced
   in the current global Internet routing table:

   1.  Section 5 discusses the LISP Proxy Ingress Tunnel Router, an
       approach that provides ITR functionality to bridge LISP-capable
       and non-
       LISP-capable non-LISP-capable sites.

   2.  Section 6 7 discusses another approach, LISP-NAT, in which NAT
       [RFC2993] is combined with ITR functionality to limit the impact
       of routable EIDs on the Internet routing infrastructure.

4.4.  Use of Routable EIDs for sites transitioning to LISP

   A primary design goal for LISP (and other Locator/ID separation
   proposals) is to facilitate topological aggregation of namespace used
   by
   for the path computation, and, thus, decrease global routing system
   overhead.  Another goal is to achieve the benefits of improved
   aggregation as soon as possible.  Individual sites advertising their
   own routes for LISP EID prefixes into the global routing system is
   therefore not recommended.

   That being said, single homed single-homed sites (or multi-homed sites that are
   not leaking more specific exceptions) and that are already using
   provider-aggregated prefixes can use these prefixes as LISP EIDs
   without adding state to the routing system.  In other words, such
   sites do not cause additional prefixes to be advertised.  For such
   sites, connectivity to a non-LISP sites site does not require interworking
   machinery because the "PA" EIDs are already routable (they are
   effectively LISP-R type sites).  Their EIDs are found in the LISP
   mapping system, and their (aggregate) PA prefix(es) are found in the
   DFZ of the Internet.

   The continued announcements of an existing site's Provider
   Independent (or "PI") prefix(es) is of course under control of that
   site.  Some period of transition, where a site is found both in the
   LISP mapping system, and as a discrete prefix in the Internet routing
   system, may be a viable transition strategy.  Care should be taken
   not to advertise additional more specific LISP EID prefixes into the
   DFZ.

5.  Proxy Ingress Tunnel Routers

   Proxy Ingress Tunnel Routers (PITRs) (Proxy-ITRs) allow for non-LISP sites to
   send packets to LISP-NR sites.  A PITR Proxy-ITR is a new network element
   that shares many characteristics with the LISP ITR.  PITRs  Proxy-ITRs allow
   non-LISP sites to send packets to LISP-NR sites without any changes
   to protocols or equipment at the non-LISP site.  PITRs  Proxy-ITRs have two
   primary functions:

   Originating EID Advertisements:  PITRs  Proxy-ITRs advertise highly
      aggregated EID-prefix space on behalf of LISP sites to so that non-LISP non-
      LISP sites can reach them.

   Encapsulating Legacy Internet Traffic:  PITRs  Proxy-ITRs also encapsulate non-
      LISP
      non-LISP Internet traffic into LISP packets and route them towards
      their destination RLOCs.

5.1.  PITR  Proxy-ITR EID announcements

   A key part of PITR Proxy-ITR functionality is to advertise routes for
   highly- aggregated EID prefixes into part parts of the global routing
   system.  Aggressive aggregation is performed to minimize the number
   of new announced routes.  In addition, careful placement of PITRs Proxy-
   ITRs can greatly reduce the advertised scope of these new routes.  To
   this end, PITRs Proxy-ITRs should be deployed close to non-LISP-speaking
   rather than close to LISP sites.  Such deployment not only limits the
   scope of EID-prefix route advertisements, it also allows traffic
   forwarding load to be spread among many PITRs. Proxy-ITRs.

5.2.  Packet Flow with PITRs Proxy-ITRs

   What follows is an example of the path a packet would take when using
   a PITR. Proxy-ITR.  In this example, the LISP-NR site is given the EID
   prefix 192.0.2.0/24.  For the purposes of this example, neither this
   prefix
   or nor any covering aggregate are present in the global routing
   system.  In other words, without the Proxy-ITR announcing
   192.0.2.0/24, if a packet with this destination were to reach a
   router in the "Default Free Zone", it would be dropped.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup EID for destination, and gets
       192.0.2.1 in return.

   2.  The source host has a default route to customer Customer Edge (CE) router
       and forwards the packet to the CE.

   3.  The CE has a default route to its Provider Edge (PE) router, and
       forwards the packet to the PE.

   4.  The PE has a route to 192.0.2.0/24 and the next hop is the PITR. Proxy-
       ITR.

   5.  The PITR Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP
       encapsulates the packet.  The outer IP header now has a
       destination address of one of the destination EID's RLOCs.  The
       outer source address of this encapsulated packet is the PITR's Proxy-
       ITR's RLOC.

   6.  The PITR Proxy-ITR looks up the RLOC, and forwards LISP packet to the
       next hop, after which, it is forwarded by other routers to the
       ETR's RLOC.

   7.  The ETR decapsulates the packet and delivers the packet to the
       192.0.2.1 host in the destination LISP site.

   8.  Packets from host 192.0.2.1 will flow back through the LISP
       site's ITR.  Such packets are not encapsulated because the ITR
       knows that the destination (the original source) is a non-LISP
       site.  The ITR knows this because it can check the LISP mapping
       database for the destination EID, and on a failure determine determines
       that the destination site is not LISP enabled.

   9.  Packets are then routed natively and directly to the destination
       (original source) site.

   Note that in this example the return path is asymmetric, so return
   traffic will not go back through the PITR. Proxy-ITR.  This is because the
   LISP-NR site's ITR will discover that the originating site is not a
   LISP site, and not encapsulate the returning packet (see [LISP] for
   details of ITR behavior).

   The asymmetric nature of traffic flows allows the PITR Proxy-ITR to be
   relatively simple - it will only have to encapsulate LISP packets.

5.3.  Scaling PITRs

   PITRs Proxy-ITRs

   Proxy-ITRs attract traffic by announcing the LISP EID namespace into
   parts of the non-LISP-speaking global routing system.  There are
   several ways that a network could control how traffic reaches a
   particular
   PITR Proxy-ITR to prevent it from receiving more traffic than
   it can handle:

   1.  The PITR's Proxy-ITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that PITR. Proxy-ITR.  For example, some of the routes being
       announced might be tagged with a BGP community and their scope of
       announcement limited by the routing policy of the provider.

   2.  The same address might be announced by multiple PITRs Proxy-ITRs in
       order to share the traffic using IP Anycast.  The asymmetric
       nature of traffic flows through the Proxy ITR Proxy-ITR means that
       operationally, deploying a set PITRs of Proxy-ITRs would be very
       similar to existing Anycasted services like DNS caches.  Multiple Proxy ITRs
       Proxy-ITRs could advertise the same BGP Next Hop IP address as
       their RLOC, and traffic would be attracted to the nearest Next
       Hop according to the network's IGP.

5.4.  Impact of the PITRs Proxy-ITRs placement in the network

   There are several approaches that a network could take in placing
   PITRs.
   Proxy-ITRs.  Placing the PITR Proxy-ITR near the source of traffic allows
   for the communication between the non-LISP site and the LISP site to
   have the least "stretch" (i.e. the least number of forwarding hops
   when compared to an optimal path between the sites).

   Some proposals, for example Core Router-Integrated Overlay [CRIO],
   have suggested grouping PITRs Proxy-ITRs near an arbitrary subset of ETRs
   and announcing a 'local' subset of EID space.  This model cannot
   guarantee minimum stretch if the EID prefix route advertisement
   points are changed (such a change might occur if a site adds,
   removes, or replaces one or more of its ISP connections).

5.5.  Benefit to Networks Deploying PITRs Proxy-ITRs

   When packets destined for LISP-NR sites arrive and are encapsulated
   at a Proxy-ITR, a new LISP packet header is pre-pended.  This causes
   the packet's destination to be set to the destination ETRs RLOC.
   Because packets are thus routed towards RLOCs, it can potentially
   better follow the Proxy-ITR network's traffic engineering policies
   (such as closest exit routing).  This also means that providers which
   are not default-free and do not deploy Proxy-ITRs end up sending more
   traffic to expensive transit links (assuming their upstreams have
   deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to
   which they may well have cheaper and closer connectivity to (via, for
   example, settlement-free peering).  A corollary to this would be that
   large transit providers, deploying PITRs Proxy-ITRs may attract more
   traffic, and therefore more revenue, from their customers.

6.  LISP-NAT

   LISP Network Address Translation (LISP-NAT) is a limited form of NAT
   [RFC2993].  LISP-NAT is designed to enable the interworking of non-  Proxy Egress Tunnel Routers

   Proxy Egress Tunnel Routers (Proxy-ETRs) allow for LISP sites and LISP-NR to send
   packets to non-LISP sites by ensuring that in the LISP-NR's case where the access network does
   not allow the LISP site
   addresses are always routable.  LISP-NAT accomplishes this by
   translating a host's to send packets with the source address from of
   the site's EID(s).  A Proxy-ETR is a new network element that,
   conceptually, acts as an 'inner' (LISP-NR EID)
   value ETR for traffic destined to non-LISP sites.
   This also has the effect of allowing an 'outer' (LISP-R) value and keeping this translation in a
   table that ITR avoid having to decide
   whether to encapsulate packets or not - it can reference for subsequent always encapsulate
   packets.

   In addition, existing RFC 1918 [RFC1918]  An ITR would encapsulate packets destined for LISP sites can use LISP-NAT to
   talk
   (no change here) and these would be routed directly to both LISP or non-LISP sites.

   The basic concept of LISP-NAT is that when transmitting a packet, the
   ITR replaces a non-routable EID source address with a routable source
   address, which enables
   corespondent site's ETR.  All other packets (those destined to return non-
   LISP sites) will be sent to the site. originating site's Proxy-ETR.

   There are two main cases that involve LISP-NAT:

   1.  Hosts at LISP sites that use non-routable global EIDs speaking to
       non-LISP sites using global addresses.

   2.  Hosts at LISP primary reasons why sites that use RFC 1918 private EIDs speaking would want to
       other sites, who may be either LISP or non-LISP.

   Note that LISP-NAT is not needed in the case of LISP-R (routable
   global EIDs) sources.  This case occurs when utilize a site is announcing its
   prefix into both the LISP mapping system as well as
   Proxy-ETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the Internet DFZ.
   This is because source of the LISP-R source's address is routable, and return packets will be able emitted to natively reach be within the site.

6.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a host with
      addressing scope of the access networks. (see section 9)

   Traversing a LISP-NR EID different IP Protocol:  A LISP site may want to send transmit
      packets to a non-LISP
   hosts by translating site where some of the LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be a either a PI intermediate network
      does not support the particular IP protocol desired (v4 or PA
   address.

   An example of v6).
      Proxy-ETRs can allow this translation follows.  For LISP site's data to 'hop over' this example, by
      utilizing LISP's support for mixed protocol encapsulation.

6.1.  Packet Flow with Proxy Egress Tunnel Routers

   Packets from a LISP site has
   been assigned can reach a LISP-NR EID of 203.0.113.0/24.  In order to utilize
   LISP-NAT, the non-LISP site has also been provided the PA EID of 192.0.2.0/24,
   and uses the first address (192.0.2.1) as with the site's RLOC.  The rest aid of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation
   pool for this site's hosts who need
   Proxy-ETR (or Proxy-ETR).  An ITR is simply configured to send packets to all
   non-LISP
   hosts.

   The translation table might look like the following:

          Site NR-EID     Site R-EID     Site's RLOC    Translation Pool
          ==============================================================
          203.0.113.0/24  192.0.2.0/24    192.0.2.1      192.0.2.2-254

                    Figure 1: Example Translation Table

   The Host 203.0.113.2 sends traffic, which it normally would have forwarded natively
   (non-encapsulated), to a packet (which, for Proxy-ETR.  In the case where the purposes of this
   example is destined for a non-LISP site) to its default route (the
   ITR).  The ITR receives uses a
   Map- Resolver(s), the packet, and determines ITR will encapsulate packets that match the
   destination is not a LISP site.  How
   received Negative Map-Cache to the configured Proxy-ETR(s).  In the
   case where the ITR makes this determination is up connected to the ITRs implementation of the EID-to-RLOC mapping system
   used (see, for example [LISP-ALT]).

   The ITR directly it
   would encapsulate all packets to the configured Proxy-ETR that are
   cache misses.  Note that this outer encapsulation to the Proxy-ETR
   may be in an IP protocol other than the (inner) encapsulated data.
   Routers then rewrites use the source LISP (outer) header's destination address of the packet from
   203.0.113.2 to 192.0.2.2, which is
   route the first available address in packets toward the
   LISP-R configured Proxy-ETR.

   A Proxy-ETR should verify the (inner) source EID space available to it.  The ITR keeps this translation in
   a table of the packet at
   time of decapsulation in order to reverse verify that this process when receiving packets
   destined is from a
   configured LISP site.  This is to 192.0.2.2.

   Finally, when prevent spoofed inner sources from
   being encapsulated through the ITR forwards this packet without encapsulating it,
   it uses Proxy-ETR.

   What follows is an example of the entry in its LISP-NAT table to translate path a packet would take when using
   a Proxy-ETR.  In this example, the returning
   packets' destination IPs to LISP-NR (or LISP-R) site is given
   the proper host.

6.2. EID prefix 192.0.2.0/24, and it is trying to reach host at a non-
   LISP Sites site with Hosts using RFC 1918 Addresses Sending to non-LISP
      Sites

   In the case where hosts using RFC 1918 addresses desire to send
   packets to non-LISP hosts, IP prefix of 198.51.100.0/24.  For the LISP-NAT implementation acts much like
   an existing IPv4 NAT device.  The ITR providing purposes of
   this example, the NAT service must
   use LISP-R EIDs for its global address pool as well as providing all destination (198.51.100.0/24) is found in the standard NAT functions required today.
   Internet's routing system.

   A full protocol exchange example follows:

   1.  The source of host makes a DNS lookup for the packet must be translated to destination, and gets
       198.51.100.100 (an IP address of a LISP-R EID host in the non-LISP site) in
       return.

   2.  The source host has a
   manner similar default route to Section 6, Customer Edge (CE) router
       and this packet must be forwarded to forwards the
   ITR's next hop for packet towards the destination, without LISP encapsulation.

6.3.  LISP Sites with Hosts using RFC 1918 Addresses   Sending Packets
      to Other LISP Sites

   LISP-NAT allows CE.

   3.  The CE is a host with an RFC 1918 address LISP ITR, and is configured to send packets encapsulate traffic
       destined for non-LISP sites to a Proxy-ETR.

   4.  The Proxy ETR decapsulates the LISP hosts by translating packet and forwards the RFC 1918 address
       original packet to a LISP EID.  After
   translation, the communication between source its next hop.

   5.  The packet is then routed natively and directly to the
       destination ITR and
   ETRs continues as described (non-LISP) site 198.51.100.0/24.

   Note that in [LISP].

   An example of this translation and encapsulation follows.  For this
   example, a host has been assigned example the return path is asymmetric, so return
   traffic will not go back through the Proxy-ETR.  This means that in
   order to reach LISP-NR sites, non-LISP sites must still use Proxy-
   ITRs.

7.  LISP-NAT

   LISP Network Address Translation (LISP-NAT) is a RFC 1918 address limited form of 192.168.1.2.
   In order NAT
   [RFC2993].  LISP-NAT is designed to utilize LISP-NAT, the site also has been provided enable the
   LISP-R EID prefix interworking of 192.0.2.0/24, non-
   LISP sites and uses the first address
   (192.0.2.1) as LISP-NR sites by ensuring that the site's RLOC.  The rest of LISP-NR's site
   addresses are always routable.  LISP-NAT accomplishes this PA space (192.0.2.2
   to 192.0.2.254) is used as by
   translating a host's source address from an 'inner' (LISP-NR EID)
   value to an 'outer' (LISP-R) value and keeping this translation pool in a
   table that it can reference for this site's hosts
   who need subsequent packets.

   In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to send packets
   talk to both non-LISP and LISP hosts.

   The Host 192.168.1.2 sends a packet destined for a or non-LISP site to
   its default route (the ITR). sites.

   The ITR receives the packet and
   determines that the destination basic concept of LISP-NAT is that when transmitting a LISP site.  How packet, the
   ITR makes
   this determination is up replaces a non-routable EID source address with a routable source
   address, which enables packets to return to the ITRs implementation of the EID/RLOC
   mapping system.

   The ITR then rewrites the source address of the packet from
   192.168.1.2 to 192.0.2.2, which is the first available address in the
   LISP EID space available to it.  The ITR keeps this translation in a
   table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   The ITR then LISP encapsulates site.  Note that this packet (see [LISP] for details).
   The ITR uses the site's RLOC as the LISP outer header's source and
   the translation address
   section is intended as the LISP inner header's source.  Once it
   decapsulates returning traffic, it uses the entry in its LISP-NAT
   table to translate the returning packet's destination IP address rough overview of what could be done and
   then forward not
   an exhaustive guide to the proper host.

6.4.  LISP-NAT and multiple EIDs

   With LISP-NAT, there IPv4 NAT.

   There are two EIDs possible for a given host, the
   LISP-R EID and the LISP-NR EID.  When a site has two addresses main cases that involve LISP-NAT:

   1.  Hosts at LISP sites that a
   host might use for global reachability, name-to-address directories
   may need to be modified.

   This problem, non-routable global vs. local addressability, exists for NAT in
   general, but the specific issue described above is unique EIDs speaking to
   location/identity separation schemes.  Some of these have suggested
   running a separate DNS instance for new types of EIDs.  This solves
   the problem but introduces complexity for the site.  Alternatively,
       non-LISP sites using PITRs can mitigate this problem, because the LISP-NR EID can be
   reached in all cases.

7.  Proxy Egress Tunnel Routers

   Proxy Egress Tunnel Routers (PETRs) allow for global addresses.

   2.  Hosts at LISP sites that use RFC 1918 private EIDs speaking to send
   packets to
       other sites, who may be either LISP or non-LISP sites sites.

   Note that LISP-NAT is not needed in the case where the access network does
   not allow for the LISP site send packets with the source address of
   the site's EID(s).  A PETR is LISP-R (routable
   global EIDs) sources.  This case occurs when a new network element that,
   conceptually, acts site is announcing its
   prefix into both the LISP mapping system as an ETR for traffic destined to non-LISP sites. well as the Internet DFZ.
   This also has is because the effect of allowing an ITR avoid having to decide
   whether to encapsulate packets or not - it can always encapsulate
   packets.  An ITR would encapsulate packets destined for LISP sites
   (no change here) LISP-R source's address is routable, and these would be routed directly to the
   corespondent site's ETR.  All other return
   packets (those destined to non-
   LISP sites) will be sent able to natively reach the originating site's PETR.

   There are two primary reasons why sites would want to utilize site.

7.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of host with a LISP-NR EID to send packets to non-LISP
   hosts by translating the packets emitted LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be within the
      addressing scope a either a PI or PA
   address.

   An example of the access networks. (see section 9)

   Traversing this translation follows.  For this example, a different IP Protocol:  A LISP site may want to transmit
      packets to has
   been assigned a non-LISP LISP-NR EID of 203.0.113.0/24.  In order to utilize
   LISP-NAT, the site where some has also been provided the PA EID of 192.0.2.0/24,
   and uses the intermediate network
      does not support first address (192.0.2.1) as the particular IP protocol desired (v4 or v6).
      PETRs can allow site's RLOC.  The rest
   of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation
   pool for this LISP site's data hosts who need to 'hop over' send packets to non-LISP
   hosts.

   The translation table might look like the following:

          Site NR-EID     Site R-EID     Site's RLOC    Translation Pool
          ==============================================================
          203.0.113.0/24  192.0.2.0/24    192.0.2.1      192.0.2.2-254

                    Figure 1: Example Translation Table

   The host 203.0.113.2 sends a packet (which, for the purposes of this by
      utilizing LISP's support
   example is destined for mixed protocol encapsulation.

7.1.  Packet Flow with Proxy Egress Tunnel Routers

   Packets from a LISP site can reach a non-LISP site with site) to its default route (the
   ITR).  The ITR receives the aid of packet, and determines that the
   destination is not a
   Proxy-ETR (or PETR).  An LISP site.  How the ITR makes this determination
   is simply configured up to send all non-
   LISP traffic, which it normally would have forwarded natively (non-
   encapsulated), the ITRs implementation of the EID-to-RLOC mapping system
   used (see, for example [LISP-ALT]).

   The ITR then rewrites the source address of the packet from
   203.0.113.2 to a PETR.  In 192.0.2.2, which is the case where first available address in the
   LISP-R EID space available to it.  The ITR uses keeps this translation in
   a Map-
   Resolver(s), table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   Finally, when the ITR will encapsulate packets that match forwards this packet without encapsulating it,
   it uses the received
   Negative Map-Cache entry in its LISP-NAT table to translate the configured Proxy-ETR(s). returning
   packets' destination IPs to the proper host.

7.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
      Sites

   In the case where
   the ITR is connected hosts using RFC 1918 addresses desire to the mapping system directly it would
   encapsulate all send
   packets to non-LISP hosts, the configured Proxy-ETR that are cache
   misses.  Note that this outer encapsulation to the Proxy-ETR may be
   in LISP-NAT implementation acts much like
   an IP protocol other than existing IPv4 NAT device that is doing address only (not port
   translation.  The ITR providing the (inner) encapsulated data.  Routers
   then NAT service must use the LISP (outer) header's destination LISP-R EIDs
   for its global address to route the
   packets toward the configured Proxy-ETR.

   A PETR should verify pool as well as providing all the (inner) standard NAT
   functions required today.

   The source EID of the packet at time of
   decapsulation must be translated to a LISP-R EID in order a
   manner similar to Section 7, and this packet must be forwarded to the
   ITR's next hop for the destination, without LISP encapsulation.

7.3.  LISP Sites with Hosts using RFC 1918 Addresses   Sending Packets
      to Other LISP Sites

   LISP-NAT allows a host with an RFC 1918 address to send packets to
   LISP hosts by translating the RFC 1918 address to verify that this is from a configured LISP
   site.  This is to prevent spoofed inner sources from being
   encapsulated through EID.  After
   translation, the Proxy-ETR.

   What follows is an communication between source and destination ITR and
   ETRs continues as described in [LISP].

   An example of the path this translation and encapsulation follows.  For this
   example, a packet would take when using host has been assigned a PETR. RFC 1918 address of 192.168.1.2.
   In this example, order to utilize LISP-NAT, the LISP-NR (or LISP-R) site is given also has been provided the
   LISP-R EID prefix of 192.0.2.0/24, and it uses the first address
   (192.0.2.1) as the site's RLOC.  The rest of this PA space (192.0.2.2
   to 192.0.2.254) is trying used as a translation pool for this site's hosts
   who need to reach send packets to both non-LISP and LISP hosts.

   The host at 192.168.1.2 sends a packet destined for a non-LISP site with to
   its default route (the ITR).  The ITR receives the IP prefix packet and
   determines that the destination is a LISP site.  How the ITR makes
   this determination is up to the ITRs implementation of 198.51.100.0/24.  For the purposes EID/RLOC
   mapping system.

   The ITR then rewrites the source address of this
   example, the destination (198.51.100.0/24) packet from
   192.168.1.2 to 192.0.2.2, which is found the first available address in the Internet's
   routing system.

   A full protocol exchange example follows:

   1.
   LISP EID space available to it.  The source host makes ITR keeps this translation in a DNS lookup
   table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   The ITR then LISP encapsulates this packet (see [LISP] for details).
   The ITR uses the destination, site's RLOC as the LISP outer header's source and gets
       198.51.100.100 (a Ip
   the translation address of a host in as the non-LISP site) LISP inner header's source.  Once it
   decapsulates returning traffic, it uses the entry in
       return.

   2.  The source host has a default route its LISP-NAT
   table to customer Edge (CE) router translate the returning packet's destination IP address and
   then forwards to the packet towards the CE.

   3.  The CE is a LISP ITR, proper host.

7.4.  LISP-NAT and is configured to encapsulate traffic
       destined multiple EIDs

   With LISP-NAT, there are two EIDs possible for non-LISP sites to a Proxy-ETR.

   4.  The Proxy ETR decapsulates the LISP packet and forwards given host, the
       original packet to its next hop.

   5.  The packet is then routed natively
   LISP-R EID and directly to the
       destination (non-LISP) LISP-NR EID.  When a site 198.51.100.0/24.

   Note has two addresses that a
   host might use for global reachability, name-to-address directories
   may need to be modified.

   This problem, global vs. local addressability, exists for NAT in this example
   general, but the return path specific issue described above is asymmetric, so return
   traffic will not go back through the Proxy-ETR.  This means that in
   order unique to reach
   location/identity separation schemes.  Some of these have suggested
   running a separate DNS instance for new types of EIDs.  This solves
   the problem but introduces complexity for the site.  Alternatively,
   using Proxy-ITRs can mitigate this problem, because the LISP-NR sites, non-LISP sites must still use Proxy
   ITRs. EID
   can be reached in all cases.

8.  Discussion of Proxy ITRs (PITRs), Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs (PETRs)
    (Proxy-ETRs)

   In summary, there are three mechanisms for interworking LISP with
   non-LISP Sites (for both IPv4 and IPv6).  In the LISP-NAT option the
   LISP site can manage and control the interworking on its own.  In the
   PITR
   Proxy-ITR case, the site is not required to manage the advertisement
   of it's EID prefix into the DFZ, with the cost of potentially adding
   stretch to the connections of non-LISP sites sending packets to the
   LISP site.  The third option is Proxy-ETRs, which are optionally used
   by sites relying on PITRs case Proxy-ITRs to mitigate two caveats for LISP sites
   sending packets to non-LISP sites.  This means Proxy-ETRs are not
   usually expected to be deployed by themselves, rather they will be
   used to assist LISP-NR sites which are already using PITRs. Proxy-ITRs.

8.1.  How Proxy-ITRs and Proxy-ETRs Interact

   There is a subtle difference between Symmetrical (LISP-NAT) vs
   Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
   Operationally, Proxy-ITRs (PITRs) (Proxy-ITRs) and Proxy-ETRs (PETRs) (Proxy-ETRs)
   can (and likely should) be decoupled since Proxy-ITRs are best
   deployed closest to non-LISP sites, and Proxy-ETRs are best located
   close to the LISP sites they are decapsulating for.  This asymmetric
   placement of the two network elements minimizes the stretch imposed
   on each direction of the packet flow, while still allowing for
   coarsely aggregated announcements of EIDs into the Internet's routing
   table.

9.  Security Considerations

   Like any router or LISP ITR, Proxy ITRs Proxy-ITRs will have the opportunity to
   inspect traffic at the time that they encapsulate.  The location of
   these devices in the network can have implications for discarding
   malicious traffic on behalf of ETRs which request this behavior (via
   the drop action bit in Map-Reply packets for an EID or EID prefix).
   This is an area that would benefit from further experimentation and
   analysis.

   LISP-Interworking via Proxy-ITRs should have no impact on the
   existing network beyond what LISP ITRs and ETRs introduce when
   multihoming.  That is, if a site multi-homes today (with LISP or BGP)
   there is a possibility of asymmetric flows.

   Proxy-ITRs and Proxy-ETRs will likely be operated by organizations
   other than those of the end site receiving or sending traffic.  Care
   should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to
   insure the quality of service meets the site's expectations.

   Proxy-ITRs and Proxy ETRs share many of the same security issues
   discussed of ITRs and ETRs.  For further information, see the
   security considerations section of [LISP].

   As with traditional NAT, LISP-NAT will obscure the actual host
   LISP-NR EID behind the LISP-R addresses used as the NAT pool.

   When LISP sites send packets to non-LISP sites (these non-LISP sites
   rely on PITRs Proxy-ITRs to enable Interworking), packets will have the Site's
   site's EID as its source IP address.  These EIDs may not be
   recognized by their Internet Service Provider's Unicast Reverse Path
   Forwarding (uRPF) rules enabled on the Provider Edge Router.  Several
   options are available to the service provider.  For example they
   could enable a less strict version of uRPF, where they only look for
   the existence of the EID prefix in the routing table.  Another, more
   secure, option is to add a static route for the customer on the PE
   router, but not redistribute this route into the provider's routing
   table.  Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF
   check by encapsulating all of their egressing egress traffic destined to non-LISP non-
   LISP sites to the Proxy-ETR (thus ensuring the outer IP source
   address is the site's RLOC).

10.  Acknowledgments

   Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael
   Menth, and Xuewei Wang, and Noel Chiappa who have made insightful
   comments with respect to LISP Interworking and transition mechanisms.

   A special thanks goes to Scott Brim for his initial brainstorming of
   these ideas and also for his careful review.

11.  IANA Considerations

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

12.  References

12.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-20 (work in progress), January 2012.

   [LISP-ALT]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)",
              draft-ietf-lisp-alt-10.txt (work in progress),
              December 2011.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-15.txt (work in progress),
              January 2012.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

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

12.2.  Informative References

   [CRIO]     Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
              Scaling IP Routing with the Core Router-Integrated
              Overlay", January 2006.

   [LISP-DEPLOY]
              Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "LISP Network Element
              Deployment Considerations",
              draft-ietf-lisp-deployment-02.txt (work in progress),
              November 2011.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027,
              January 2001.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

Authors' Addresses

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Cisco Systems, Inc.

   Email: dmm@cisco.com

   Dino Farinacci
   Cisco Systems, Inc.

   Email: dino@cisco.com

   Vince Fuller
   Cisco Systems, Inc.

   Email: vaf@cisco.com