From darlewis@cisco.com Fri Feb 3 10:21:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5C021F855E for ; Fri, 3 Feb 2012 10:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.051 X-Spam-Level: X-Spam-Status: No, score=-4.051 tagged_above=-999 required=5 tests=[AWL=-2.548, BAYES_20=-0.74, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5IEJVAcrvyK for ; Fri, 3 Feb 2012 10:21:40 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9809221F84CF for ; Fri, 3 Feb 2012 10:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=62422; q=dns/txt; s=iport; t=1328293300; x=1329502900; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=5k2PXgRzjjjF0RepEtUisRzQXW5S41MqyqMBxmmtGwM=; b=CGfsRsz+toOBAv+MdjcZZUhUAB5gruDf+EdCLcotb1u2hIqduJTh6yX8 nhaWCN8516pbLDPDNMWkZ4+DMlCJhmVsD1QmfelqWHnpXqsmj4WsEqHuW SxcKjz6VDbQOazgQRVIVeBNdLVluYRXjscjzMsZNsttqUpyeH7FdUxQeT E=; X-Files: draft-ietf-lisp-interworking-03.txt : 43944 X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="txt'?scan'208";a="28433789" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 03 Feb 2012 18:21:40 +0000 Received: from sjc-vpn5-1139.cisco.com (sjc-vpn5-1139.cisco.com [10.21.92.115]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q13ILc8q029301; Fri, 3 Feb 2012 18:21:39 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_0FA1F1EE-B04C-44FF-A28E-0B3311D4E291" From: Darrel Lewis In-Reply-To: <4F017880.3060500@piuha.net> Date: Fri, 3 Feb 2012 10:21:37 -0800 Message-Id: References: <4F017880.3060500@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:21:44 -0000 --Apple-Mail=_0FA1F1EE-B04C-44FF-A28E-0B3311D4E291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jari, Sorry for taking so long to respond to your review. Please find = suggested text below as well as a proposed -03 draft attached. On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote: > I have reviewed this document. >=20 > In general, it is well written and almost ready to go forward. There = are a couple of areas that need further text, however. The main issue is = a clear description of the to-experiment and problematic areas of LISP = interworking. (Making those is also needed in order to get the document = approved, based on experience of taking the other Lisp documents to the = IESG.) Another issue is that I think the security considerations text = needs work. >=20 > In moder detail: >=20 > Technical issue: As with the other documents from the group, Section 1 = should include a high-level explanation of what issues are uncertain, = potentially problematic, or worth experimenting on. For instance, I = presume you should say something about the effects of having to NAT = traffic, finding deployment motivations to set up proxy ITRs, possible = inclusion of too much non-aggregated EID space in the DFZ, effects of = the asymmetric PITR routing, and so on. >=20 > Please suggest text. I suggest adding the following paragraph to the end of the Introduction = (Section 1). Several areas concerning the Interworking of LISP and non-LISP sites = remain open=20 for further study. These areas include an examination the impact of = LISP-NAT on internet traffic and applications, understanding the deployment = motivations for the deployment and operation of Proxy Tunnel Routers, the impact of = EID routes=20 originated by these Proxy Tunnel Routers into the Internet's Default = Free Zone, and the effects of Proxy Tunnel Routers on internet traffic and = applications. of Proxy Tunnel Routers on internet traffic and applications. This = analysis will explain what role Proxy Tunnel Routers and NAT will play in the = expected ongoing=20 presence of both LISP and non-LISP sites in the Internet. >=20 >> An ITR can also know explicitly that the >> destination is non-LISP if the destination IP address matches a >> Negative Map Reply found in its Map Cache. >=20 > Technical issue: This is normally the case, but the text seems to = avoid going into the details that I think are relevant in this case. The = base spec says >=20 > There are two primary applications for > Negative Map-Replies. The first is for a Map-Resolver to instruct = an > ITR or PITR when a destination is for a LISP site versus a non-LISP > site. And the other is to source quench Map-Requests which are sent > for non-allocated EIDs. >=20 > and >=20 > The actions defined are used by an ITR or PITR when a > destination EID matches a negative mapping cache entry. > Unassigned values should cause a map-cache entry to be created > and, when packets match this negative cache entry, they will be > dropped. The current assigned values are: >=20 > (0) No-Action: The map-cache is kept alive and no packet > encapsulation occurs. >=20 > (1) Natively-Forward: The packet is not encapsulated or dropped > but natively forwarded. >=20 > (2) Send-Map-Request: The packet invokes sending a Map-Request. >=20 > (3) Drop: A packet that matches this map-cache entry is dropped. > An ICMP Unreachable message SHOULD be sent. >=20 > That is, first of all there are other situations for which negative = map cache entries are used (but it is probably fine to route to the = Internet in those cases). Secondly, there are some controls on whether = native forwarding is the appropriate action. >=20 > Can you add a note about these and/or reformulate the text a bit? Yes this is a good suggestion. Interworking pre-dated negative = map-replies so the text hear isn't as clear as it should be. How about: 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 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. This can be achieved=20= by using one of two mechanisms: 1. At the ITR in the source site, if the destination of an IP packet is found to match a prefix from the BGP routing table, then the site is directly reachable by the BGP core as it exists and operates today. 2. An ITR knows explicitly that the destination is non-LISP if the destination IP address of an IP packet matches a (negative)=20 Map-Cache entry which has the action 'Natively-Forward'. There are some situations where (un-encapsulated) packets originated = by a LISP site may not get forwarded successfully to a non-LISP site.=20 These situations are reviewed in section 7, (Proxy-Egress Tunnel = Routers). >=20 >> 3. In either of the two exceptions mentioned above there could be >>=20 >=20 > Editorial issue: I was unsure what "the two exceptions mentioned = above" refer to. Also, your list starts with "This can be achieved by = using one of two mechanisms:", so it is odd to find three items in the = list. I would suggest making this paragraph a regular paragraph and not = a numbered item, and starting it with "In either of the two mechanisms = listed above there could be =85" Fixed. See above, I believe this is addressed in the suggested text. > . >=20 >> 5. Proxy Ingress Tunnel Routers >=20 > Editorial issue: It may be too obvious perhaps, but I think this = section should state up front that highly aggregated EID space = advertisement implies an entity that routes on the behalf of many LISP = sites. >=20 >> 240.0.0.0/24. For the purposes of this example, this prefix and = no >>=20 >=20 > Editorial issue: Is there a reason why we are using 240 addresses as = examples? I'd prefer using normal example addresses or 10/8 addresses if = you need shorter prefixes=85 I have changed the documentation prefixes, I think we do not need = shorter prefixes in these examples. >=20 >> For the purposes of this example, this prefix and no >> covering aggregate is present in the global routing system. >=20 > Editorial issue: Shouldn't this be "... neither this prefix or any = covering aggregate are present ...". The way that you have written it = now had me confused for a moment, thinking that this prefix is present = but no covering prefix is present. I don't think that is what you mean. >=20 Yes good catch, fixed. >>=20 >> 6 = . = LISP-NAT >>=20 >>=20 >>=20 >=20 > Technical issue: Section 6 should probably point to some BEHAVE WG = RFCs on how the NAT operation should technically work. Ok I will added >=20 >> An example of this translation follows. For this example, a site has >> been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize >> LISP-NAT, the site has also been provided the PA EID of >> 128.200.1.0/24, and uses the first address (128.200.1.1) as the >> site's RLOC. The rest of this PA space (128.200.1.2 to >> 128.200.1.254) is used as a translation pool for this site's hosts >> who need to send packets to non-LISP hosts. >>=20 > Editorial issue: Please use the officially allocated example = addresses. >=20 Fixed. >>=20 >> 6.4 = . = LISP-NAT and multiple EIDs >>=20 >>=20 >>=20 >> When a site has two addresses that a host might use for global >> reachability, care must be chosen on which EID is found in DNS. = For >> example, whether applications such as DNS use the LISP-R EID or = the >> LISP-NR EID. This problem exists for NAT in general, but the >> specific issue described above is unique to LISP. Using PITRs can >> mitigate this problem, since the LISP-NR EID can be reached in all >> cases. >=20 > Technical issue: but if you had a PITR, you would not need LISP-NAT, = or am I missing something? I agree (which you below) that Section 6.4 is redundant with 6.5, since = 6.5 is more clearer and more complete and I suggest keeping it and = removing the above. >=20 >>=20 >> 6.5 = . = When LISP-NAT and PITRs used by the same LISP Site >>=20 >>=20 >>=20 >> With LISP-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 = that a >> host might use for global reachability, name-to-address = directories >> may need to be modified. >>=20 >> This problem, global vs. local addressability, exists for NAT in >> general, but the specific issue described above is unique 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, >> using PITRs can mitigate this problem, because the LISP-NR EID can = be >> reached in all cases. >=20 > Editorial issue: what's the difference between Sections 6.4 and 6.5? = It seems that they both talk about the problem of two addresses in a = name mapping system. >=20 > Technical issue: I don't think "introduces complexity for the site" = begins to explain the type of problems caused by having to separate = naming systems from each other. Please expand or otherwise highlight = that this approach is problematic. I agree that the problems here deserve further highlighting. I suggest = adding the following changes to section 6.5. >=20 >>=20 >> 8 = . = Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) >>=20 >>=20 >>=20 >> 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 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 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. >>=20 >=20 > Technical issue: This paragraph and Setion 8 in general would greatly = from a discussion of the tradeoffs involved in these three mechanisms. = Just one downside, stretch, is mentioned above. But I think there are = others... impacts to naming systems, asymmetric traffic, etc. Please = expand. I=20 >=20 >> 9. Security Considerations >=20 > Technical issue: This section seems a bit thin. I'd love to see a = discussion of the following additional issues: >=20 > Implications to firewalls? Are there any? What about asymmetric = routing? I don't now of any implications to firewalls, asymmetric routing is = problematic for any multi-homed site and its my belief that = LISP-Interworking has no impact on this beyond what LISP introduces with = multihoming. That is, if you multi-home today (with LISP or BGP) you = get the possibility of asymmetric flows. Interworking's schemes, by = themselves, don't seem to me to change that. However, if you can = suggest some specific examples to guide this discussion I'll be happy to = produce some text, I just can't think of anything right now. >=20 > Are there Denial-of-service attacks on PITRs and PETRs? =46rom the perspective of general Interworking, this is no different = than ITRs or ETRs, as far as I can see. The LISP Deployment draft might = benefit from some discussion here (due to placement in the network = topology etc). Based on your note below I will add a reference to the = base spec for this. >=20 > Are there DNSSEC implications on the naming system implications? None that I can see, since with LISP-NAT both LISP-R and LISP-NR = addresses 'belong' to the same site. (but again if you have some = specific guidance here I am open to suggestions). >=20 >> Like any router or LISP ITR, PITRs 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). >>=20 >=20 > You should also talk about these devices being trusted to route your = traffic to begin with, and how both non-Lisp and Lisp networks should be = careful in not peering with untrustworthy networks. Ok adding some text here. Note that the Deployment draft goes into = some more detail about Originating EID-Routes and the impact of SIDR on = PITRs. > This is very similar to, say, peering with someone who says they can = reach everything in the Internet but in reality their quality or = security leaves something to be desired. yes good point, and this is unique to interworking (though I can see an = analogy to selecting a mapping service provider) How about this text for the security considerations section: Like any router or LISP ITR, 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=20= analysis. 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=20 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. =20 When LISP sites send packets to non-LISP sites (these non-LISP sites rely on PITRs to enable Interworking), packets will have the 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 traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring the outer IP source address is the site's RLOC). >=20 > (Of course, all additions to the security considerations text could be = pointers elsewhere, if the issues have already been noted in other = documents.) Right I can point to [LISP] for the cases where Proxy-ITRs and = Proxy-ETRs are similar to ITRs and ETRs. Thanks again for your careful review! -Darrel, on behalf of the other LISP-Interworking authors. --Apple-Mail=_0FA1F1EE-B04C-44FF-A28E-0B3311D4E291 Content-Disposition: attachment; filename=draft-ietf-lisp-interworking-03.txt Content-Type: text/plain; name="draft-ietf-lisp-interworking-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Lewis Internet-Draft D. Meyer Intended status: Experimental D. Farinacci Expires: August 6, 2012 V. Fuller Cisco Systems, Inc. February 3, 2012 Interworking LISP with IPv4 and IPv6 draft-ietf-lisp-interworking-03.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) (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 Proxy Egress Tunnel Router (PETR) 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." Lewis, et al. Expires August 6, 2012 [Page 1] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 This Internet-Draft will expire on August 6, 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. Lewis, et al. Expires August 6, 2012 [Page 2] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 9 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 9 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 9 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 9 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 11 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 11 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 11 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Impact of the PITRs placement in the network . . . . . . . 13 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 13 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 14 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 15 6.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets to Other LISP Sites . . . . . . . . . . . 15 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 16 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 17 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 17 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Lewis, et al. Expires August 6, 2012 [Page 3] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 1. Introduction This document describes interoperation 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 is that EID prefixes are normally not advertised into the Internet's Default Free Zone (DFZ). Specifically, only 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) 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), 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 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 - Section 6 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 Lewis, et al. Expires August 6, 2012 [Page 4] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 - Section 8 describes the relationship between asymmetric and 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 the impact of LISP-NAT on internet traffic and applications, understanding the deployment motivations for the deployment and operation of Proxy Tunnel Routers, the impact of EID routes originated by these Proxy Tunnel Routers into the Internet's Default Free Zone,and the effects of Proxy Tunnel Routers on internet traffic and applications. This analysis will explain what role Proxy Tunnel Routers and NAT will play in the expected ongoing presence of both LISP and non-LISP sites in the Internet. Lewis, et al. Expires August 6, 2012 [Page 5] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 2. 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 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. This can be achieved by using one of two mechanisms: 1. At the ITR in the source site, if the destination of an IP packet is found to match a prefix from the BGP routing table, then the site is directly reachable by the BGP core as it exists and operates today. 2. 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'. In either of the two exceptions mentioned above 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 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 Lewis, et al. Expires August 6, 2012 [Page 6] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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) and Section 6 (LISP-NAT) describe two such mechanisms. Case 4 also applies to packets returning to the LISP site, in Case 3. Lewis, et al. Expires August 6, 2012 [Page 7] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 3. Definition of Terms LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only, these EIDs are not found in the legacy Internet routing table. LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide interconnectivity between sites which use LISP EIDs and those which do not. They act as gateways between those parts of the Internet which are not using LISP (the legacy Internet) A given PITR advertises one or more highly aggregated EID prefixes into the public Internet and acts as the ITR for traffic received from the public Internet. LISP Proxy Ingress Tunnel Routers are described in Section 5. LISP Network Address Translation (LISP-NAT): Network Address Translation between EID space assigned to 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 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]. Lewis, et al. Expires August 6, 2012 [Page 8] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 to EID space without changing its existing routing policy. 4.2. Requirement for using BGP Non-LISP sites today use BGP to, among other things, enable ingress traffic engineering. Relaxing this requirement 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 Tunnel Router, an approach that provides ITR functionality to bridge LISP-capable and non- LISP-capable sites. 2. Section 6 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 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. Lewis, et al. Expires August 6, 2012 [Page 9] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 That being said, 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 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 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. Lewis, et al. Expires August 6, 2012 [Page 10] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 5. Proxy Ingress Tunnel Routers Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send packets to LISP-NR sites. A PITR is a new network element that shares many characteristics with the LISP ITR. PITRs allow non-LISP sites to send packets to LISP-NR sites without any changes to protocols or equipment at the non-LISP site. PITRs have two primary functions: Originating EID Advertisements: PITRs advertise highly aggregated EID-prefix space on behalf of LISP sites to so that non-LISP sites can reach them. Encapsulating Legacy Internet Traffic: PITRs also encapsulate non- LISP Internet traffic into LISP packets and route them towards their destination RLOCs. 5.1. PITR EID announcements A key part of PITR functionality is to advertise routes for highly- aggregated EID prefixes into part of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of PITRs can greatly reduce the advertised scope of these new routes. To this end, PITRs 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. 5.2. Packet Flow with PITRs What follows is an example of the path a packet would take when using a PITR. 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 any covering aggregate are present in the global routing system. In other words, without the Proxy-ITR announcing 192.0.2.0/24, 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 Edge (CE) router and forwards the packet to the CE. Lewis, et al. Expires August 6, 2012 [Page 11] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 3. The CE has a default route to its Provider Edge (PE) router, and forwards the packet to the PE. 4. The PE has route to 192.0.2.0/24 and the next hop is the PITR. 5. The PITR 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 RLOC. 6. The PITR 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 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. 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 to be relatively simple - it will only have to encapsulate LISP packets. 5.3. Scaling PITRs PITRs 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 to prevent it from receiving more traffic than it can handle: 1. The PITR's aggregate routes might be selectively announced, giving a coarse way to control the quantity of traffic attracted by that PITR. For example, some of the routes being announced might be tagged with a BGP community and their scope of Lewis, et al. Expires August 6, 2012 [Page 12] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 announcement limited by the routing policy of the provider. 2. The same address might be announced by multiple PITRs in order to share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy ITR means that operationally, deploying a set PITRs would be very similar to existing Anycasted services like DNS caches. Multiple 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 placement in the network There are several approaches that a network could take in placing PITRs. Placing the PITR 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 CRIO [CRIO], have suggested grouping PITRs 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 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 may attract more traffic, and therefore more revenue, from their customers. Lewis, et al. Expires August 6, 2012 [Page 13] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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- LISP sites and LISP-NR sites by ensuring that the LISP-NR's site addresses are always routable. LISP-NAT accomplishes this by translating a host's source address from an 'inner' (LISP-NR EID) value to an 'outer' (LISP-R) value and keeping this translation in a table that it can reference for subsequent packets. In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk 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 packets to return to the site. 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 sites that use RFC 1918 private EIDs speaking 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 a site is announcing its prefix into both the LISP mapping system as well as the Internet DFZ. This is because the LISP-R source's address is routable, and return packets will be able to natively reach the site. 6.1. Using LISP-NAT with LISP-NR EIDs LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). This globally unique address may be a either a PI or PA address. An example of this translation follows. For this example, a site has been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize LISP-NAT, the site has also been provided the PA EID of 128.200.1.0/24, and uses the first address (128.200.1.1) as the site's RLOC. The rest of this PA space (128.200.1.2 to 128.200.1.254) is used as a translation pool for this site's hosts who need to send packets to non-LISP hosts. The translation table might look like the following: Lewis, et al. Expires August 6, 2012 [Page 14] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 Site NR-EID Site R-EID Site's RLOC Translation Pool =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254 Figure 1: Example Translation Table The Host 220.1.1.2 sends a packet (which, for the purposes of this example is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet, and determines that the destination is not a LISP site. How the ITR makes this determination is up to 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 220.1.1.2 to 128.200.1.2, which is the first available address in the LISP-R EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 128.200.1.2. Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the returning packets' destination IPs to the proper host. 6.2. LISP Sites 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, the LISP-NAT implementation acts much like an existing IPv4 NAT device. The ITR providing the NAT service must use LISP-R EIDs for its global address pool as well as providing all the standard NAT functions required today. The source of the packet must be translated to a LISP-R EID in a manner similar to Section 6, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation. 6.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 a LISP EID. After translation, the communication between source and destination ITR and ETRs continues as described in [LISP]. An example of this translation and encapsulation follows. For this example, a host has been assigned a RFC 1918 address of 192.168.1.2. In order to utilize LISP-NAT, the site also has been provided the LISP-R EID prefix of 192.0.2.0/24, and uses the first address Lewis, et al. Expires August 6, 2012 [Page 15] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 (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 used as a translation pool for this site's hosts who need to send packets to both non-LISP and LISP hosts. The Host 192.168.1.2 sends a packet destined for a non-LISP site to its default route (the ITR). The ITR receives the packet and determines that the destination is a LISP site. How the ITR makes this determination is up 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 this packet (see [LISP] for details). The ITR uses the site's RLOC as the LISP outer header's source and the translation address 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 and then forward to the proper host. 6.4. LISP-NAT and multiple EIDs With LISP-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 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 general, but the specific issue described above is unique 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, using PITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases. Lewis, et al. Expires August 6, 2012 [Page 16] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 7. Proxy Egress Tunnel Routers Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send packets to non-LISP sites 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 a new network element that, conceptually, acts as an ETR for traffic destined to non-LISP sites. This also has 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) and these would be routed directly to the corespondent site's ETR. All other packets (those destined to non- LISP sites) will be sent to the originating site's PETR. There are two primary reasons why sites would want to utilize a PETR: Avoiding strict uRPF failures: Some provider's access networks require the source of the packets emitted to be within the addressing scope of the access networks. (see section 9) Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where some of the intermediate network does not support the particular IP protocol desired (v4 or v6). PETRs can allow this LISP site's data to 'hop over' this by utilizing LISP's support 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 the aid of a Proxy-ETR (or PETR). An ITR is simply configured to send all non- LISP traffic, which it normally would have forwarded natively (non- encapsulated), to a PETR. In the case where the ITR uses a Map- Resolver(s), the ITR will encapsulate packets that match the received Negative Map-Cache to the configured Proxy-ETR(s). In the case where the ITR is connected to the mapping system 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 use the LISP (outer) header's destination address to route the packets toward the configured Proxy-ETR. A PETR should verify the (inner) source EID of the packet at time of decapsulation in order to verify that this is from a configured LISP site. This is to prevent spoofed inner sources from being encapsulated through the Proxy-ETR. What follows is an example of the path a packet would take when using a PETR. In this example, the LISP-NR (or LISP-R) site is given the Lewis, et al. Expires August 6, 2012 [Page 17] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP site with the IP prefix of 198.51.100.0/24. For the purposes of this example, the destination (198.51.100.0/24) is found in the Internet's routing system. A full protocol exchange example follows: 1. The source host makes a DNS lookup for the destination, and gets 198.51.100.100 (a Ip address of a host in the non-LISP site) in return. 2. The source host has a default route to customer Edge (CE) router and forwards the packet towards the CE. 3. The CE is a LISP ITR, and is configured to encapsulate traffic destined for non-LISP sites to a Proxy-ETR. 4. The Proxy ETR decapsulates the LISP packet and forwards the original packet to its next hop. 5. The packet is then routed natively and directly to the destination (non-LISP) site 198.51.100.0/24. Note that in this 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. Lewis, et al. Expires August 6, 2012 [Page 18] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) 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 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 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. 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) and Proxy-ETRs (PETRs) 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. Lewis, et al. Expires August 6, 2012 [Page 19] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 9. Security Considerations Like any router or LISP ITR, 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. 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 to enable Interworking), packets will have the 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 traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring the outer IP source address is the site's RLOC). Lewis, et al. Expires August 6, 2012 [Page 20] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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. Lewis, et al. Expires August 6, 2012 [Page 21] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 11. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. Lewis, et al. Expires August 6, 2012 [Page 22] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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). [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Lewis, et al. Expires August 6, 2012 [Page 23] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. Lewis, et al. Expires August 6, 2012 [Page 24] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 Lewis, et al. Expires August 6, 2012 [Page 25] =0C --Apple-Mail=_0FA1F1EE-B04C-44FF-A28E-0B3311D4E291 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_0FA1F1EE-B04C-44FF-A28E-0B3311D4E291-- From jmh@joelhalpern.com Fri Feb 3 10:36:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57C621F85C2 for ; Fri, 3 Feb 2012 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSJenE9uwn0l for ; Fri, 3 Feb 2012 10:36:04 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5965921F84E2 for ; Fri, 3 Feb 2012 10:36:04 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C2C3CCD2A1 for ; Fri, 3 Feb 2012 10:36:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 738581BD4A82; Fri, 3 Feb 2012 10:36:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BB6411BD4A84; Fri, 3 Feb 2012 10:35:59 -0800 (PST) Message-ID: <4F2C290B.7040603@joelhalpern.com> Date: Fri, 03 Feb 2012 13:35:55 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Darrel Lewis References: <4F017880.3060500@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:36:04 -0000 I am a bit concerned that the description of the cases does not work. In particular, if I am reading the text (preserved below) properly, it says that the ITR can use the presence of a covering prefix in the regular BGP table to tell that a destination is a non-LISP destination. But in order for interworking to function, all LISP EIDs must fall into prefixes which are advertised into the regular BGP routing table by PITRs somewhere. As such, it seems that decision process 1 below would be counter-productive, sending all LISP-LISP traffic through PITRs. Since I know that what I am inferring is not what you intend, we need better text please. Yours, Joel On 2/3/2012 1:21 PM, Darrel Lewis wrote: > Yes this is a good suggestion. Interworking pre-dated negative map-replies so the text hear isn't as clear as it should be. How about: > > > 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 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. This can be achieved > by using one of two mechanisms: > > 1. At the ITR in the source site, if the destination of an IP packet > is found to match a prefix from the BGP routing table, then the > site is directly reachable by the BGP core as it exists and > operates today. > > 2. 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 are some situations where (un-encapsulated) packets originated by a > LISP site may not get forwarded successfully to a non-LISP site. > These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers). From darlewis@cisco.com Fri Feb 3 12:10:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6732E21F858F for ; Fri, 3 Feb 2012 12:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjmWOn5J11Ht for ; Fri, 3 Feb 2012 12:10:56 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B103321F85E5 for ; Fri, 3 Feb 2012 12:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=2601; q=dns/txt; s=iport; t=1328299856; x=1329509456; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ghdckUa9PUlD4scsSzbo1d9Ofred9no8Cwy6dXqS2mw=; b=gKd/IekKDBUKCselSixrW2w9TZ1m9CLEATfocg7CTF8N4myDJPJZypnJ hBg4BCWmbCkaAInM0V8ZCZu78+fQu6mdJHy6F11Ete84IyQxN+hPe5Chv vVMAnkFTFeKIGW7+X611G3EyztO8nHikvIzWTkQwO1HPm5iOH4S77qwls Y=; X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="28602312" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Feb 2012 20:10:56 +0000 Received: from [10.21.74.30] ([10.21.74.30]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q13KAt4J023339; Fri, 3 Feb 2012 20:10:55 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Darrel Lewis In-Reply-To: <4F2C290B.7040603@joelhalpern.com> Date: Fri, 3 Feb 2012 12:10:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8531F9A6-AC66-4265-A3E3-EFD6F9F7B09C@cisco.com> References: <4F017880.3060500@piuha.net> <4F2C290B.7040603@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:10:57 -0000 On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote: > I am a bit concerned that the description of the cases does not work. > In particular, if I am reading the text (preserved below) properly, it = says that the ITR can use the presence of a covering prefix in the = regular BGP table to tell that a destination is a non-LISP destination. > But in order for interworking to function, all LISP EIDs must fall = into prefixes which are advertised into the regular BGP routing table by = PITRs somewhere. As such, it seems that decision process 1 below would = be counter-productive, sending all LISP-LISP traffic through PITRs. >=20 > Since I know that what I am inferring is not what you intend, we need = better text please. >=20 Good point Joel, I think the text confuses the issue. At this point the = right way for a device to determine if the destination is LISP is to = _look into the mapping system_ not the DFZ. How about simply removing = the first numbered bullet, and adjusting the text? I also noticed that I didn't provide in response to Jari on Section 8. = (though i right now I am at a loss for exactly what text to include I = will think about it. and reply this weekend. -D > Yours, > Joel >=20 > On 2/3/2012 1:21 PM, Darrel Lewis wrote: >> Yes this is a good suggestion. Interworking pre-dated negative = map-replies so the text hear isn't as clear as it should be. How about: >>=20 >>=20 >> 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 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. This can be = achieved >> by using one of two mechanisms: >>=20 >> 1. At the ITR in the source site, if the destination of an IP = packet >> is found to match a prefix from the BGP routing table, then = the >> site is directly reachable by the BGP core as it exists and >> operates today. >>=20 >> 2. 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'. >>=20 >> There are some situations where (un-encapsulated) packets = originated by a >> LISP site may not get forwarded successfully to a non-LISP site. >> These situations are reviewed in section 7, (Proxy-Egress Tunnel = Routers). From jmh@joelhalpern.com Fri Feb 3 12:14:31 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32EC11E8073 for ; Fri, 3 Feb 2012 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4ZyC-sAd6Tq for ; Fri, 3 Feb 2012 12:14:31 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4611E8071 for ; Fri, 3 Feb 2012 12:14:31 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 2C4F3CD3C0 for ; Fri, 3 Feb 2012 12:14:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F27831BD56BB; Fri, 3 Feb 2012 12:14:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9B9A11BD56B1; Fri, 3 Feb 2012 12:14:29 -0800 (PST) Message-ID: <4F2C401E.7020203@joelhalpern.com> Date: Fri, 03 Feb 2012 15:14:22 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Darrel Lewis References: <4F017880.3060500@piuha.net> <4F2C290B.7040603@joelhalpern.com> <8531F9A6-AC66-4265-A3E3-EFD6F9F7B09C@cisco.com> In-Reply-To: <8531F9A6-AC66-4265-A3E3-EFD6F9F7B09C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:14:31 -0000 Removing option 1 would solve my concern very nicely. Thanks. Joel On 2/3/2012 3:10 PM, Darrel Lewis wrote: > > On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote: > >> I am a bit concerned that the description of the cases does not work. >> In particular, if I am reading the text (preserved below) properly, it says that the ITR can use the presence of a covering prefix in the regular BGP table to tell that a destination is a non-LISP destination. >> But in order for interworking to function, all LISP EIDs must fall into prefixes which are advertised into the regular BGP routing table by PITRs somewhere. As such, it seems that decision process 1 below would be counter-productive, sending all LISP-LISP traffic through PITRs. >> >> Since I know that what I am inferring is not what you intend, we need better text please. >> > > Good point Joel, I think the text confuses the issue. At this point the right way for a device to determine if the destination is LISP is to _look into the mapping system_ not the DFZ. How about simply removing the first numbered bullet, and adjusting the text? > > I also noticed that I didn't provide in response to Jari on Section 8. (though i right now I am at a loss for exactly what text to include I will think about it. and reply this weekend. > > -D > >> Yours, >> Joel >> >> On 2/3/2012 1:21 PM, Darrel Lewis wrote: >>> Yes this is a good suggestion. Interworking pre-dated negative map-replies so the text hear isn't as clear as it should be. How about: >>> >>> >>> 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 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. This can be achieved >>> by using one of two mechanisms: >>> >>> 1. At the ITR in the source site, if the destination of an IP packet >>> is found to match a prefix from the BGP routing table, then the >>> site is directly reachable by the BGP core as it exists and >>> operates today. >>> >>> 2. 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 are some situations where (un-encapsulated) packets originated by a >>> LISP site may not get forwarded successfully to a non-LISP site. >>> These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers). > > From jari.arkko@piuha.net Mon Feb 6 06:43:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB621F85FB for ; Mon, 6 Feb 2012 06:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6-8zBO23T7z for ; Mon, 6 Feb 2012 06:43:33 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7E21F85CF for ; Mon, 6 Feb 2012 06:43:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0BBA92CDC4; Mon, 6 Feb 2012 16:43:32 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afLC4zjNRQlG; Mon, 6 Feb 2012 16:43:27 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 51F3C2CC39; Mon, 6 Feb 2012 16:43:27 +0200 (EET) Message-ID: <4F2FE70E.6080005@piuha.net> Date: Mon, 06 Feb 2012 16:43:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Darrel Lewis References: <4F017880.3060500@piuha.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:43:35 -0000 On 03.02.2012 20:21, Darrel Lewis wrote: > Jari, > > Sorry for taking so long to respond to your review. Please find suggested text below as well as a proposed -03 draft attached. > > On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote: > >> I have reviewed this document. >> >> In general, it is well written and almost ready to go forward. There are a couple of areas that need further text, however. The main issue is a clear description of the to-experiment and problematic areas of LISP interworking. (Making those is also needed in order to get the document approved, based on experience of taking the other Lisp documents to the IESG.) Another issue is that I think the security considerations text needs work. >> >> In moder detail: >> >> Technical issue: As with the other documents from the group, Section 1 should include a high-level explanation of what issues are uncertain, potentially problematic, or worth experimenting on. For instance, I presume you should say something about the effects of having to NAT traffic, finding deployment motivations to set up proxy ITRs, possible inclusion of too much non-aggregated EID space in the DFZ, effects of the asymmetric PITR routing, and so on. >> >> Please suggest text. > I suggest adding the following paragraph to the end of the Introduction (Section 1). > > Several areas concerning the Interworking of LISP and non-LISP sites remain open > for further study. These areas include an examination the impact of LISP-NAT on > internet traffic and applications, understanding the deployment motivations for > the deployment and operation of Proxy Tunnel Routers, the impact of EID routes > originated by these Proxy Tunnel Routers into the Internet's Default Free Zone, > and the effects of Proxy Tunnel Routers on internet traffic and applications. > of Proxy Tunnel Routers on internet traffic and applications. This analysis will > explain what role Proxy Tunnel Routers and NAT will play in the expected ongoing > presence of both LISP and non-LISP sites in the Internet. Some duplication above ("of Proxy ....") I like the beginning part, but I would replace the last sentence with: "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." (I think that is a true statement. And I'm not trying to be negative, but from processing the other docs in the IESG, it is clear that we cannot get the documents approved without safety warnings like this.) > > >>> An ITR can also know explicitly that the >>> destination is non-LISP if the destination IP address matches a >>> Negative Map Reply found in its Map Cache. >> Technical issue: This is normally the case, but the text seems to avoid going into the details that I think are relevant in this case. The base spec says >> >> There are two primary applications for >> Negative Map-Replies. The first is for a Map-Resolver to instruct an >> ITR or PITR when a destination is for a LISP site versus a non-LISP >> site. And the other is to source quench Map-Requests which are sent >> for non-allocated EIDs. >> >> and >> >> The actions defined are used by an ITR or PITR when a >> destination EID matches a negative mapping cache entry. >> Unassigned values should cause a map-cache entry to be created >> and, when packets match this negative cache entry, they will be >> dropped. The current assigned values are: >> >> (0) No-Action: The map-cache is kept alive and no packet >> encapsulation occurs. >> >> (1) Natively-Forward: The packet is not encapsulated or dropped >> but natively forwarded. >> >> (2) Send-Map-Request: The packet invokes sending a Map-Request. >> >> (3) Drop: A packet that matches this map-cache entry is dropped. >> An ICMP Unreachable message SHOULD be sent. >> >> That is, first of all there are other situations for which negative map cache entries are used (but it is probably fine to route to the Internet in those cases). Secondly, there are some controls on whether native forwarding is the appropriate action. >> >> Can you add a note about these and/or reformulate the text a bit? > Yes this is a good suggestion. Interworking pre-dated negative map-replies so the text hear isn't as clear as it should be. How about: > > > 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 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. This can be achieved > by using one of two mechanisms: > > 1. At the ITR in the source site, if the destination of an IP packet > is found to match a prefix from the BGP routing table, then the > site is directly reachable by the BGP core as it exists and > operates today. > > 2. 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 are some situations where (un-encapsulated) packets originated by a > LISP site may not get forwarded successfully to a non-LISP site. > These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers). OK > > >>> 3. In either of the two exceptions mentioned above there could be >>> >> Editorial issue: I was unsure what "the two exceptions mentioned above" refer to. Also, your list starts with "This can be achieved by using one of two mechanisms:", so it is odd to find three items in the list. I would suggest making this paragraph a regular paragraph and not a numbered item, and starting it with "In either of the two mechanisms listed above there could be …" > Fixed. See above, I believe this is addressed in the suggested text. OK > > >> . >> >>> 5. Proxy Ingress Tunnel Routers >> Editorial issue: It may be too obvious perhaps, but I think this section should state up front that highly aggregated EID space advertisement implies an entity that routes on the behalf of many LISP sites. >> >>> 240.0.0.0/24. For the purposes of this example, this prefix and no >>> >> Editorial issue: Is there a reason why we are using 240 addresses as examples? I'd prefer using normal example addresses or 10/8 addresses if you need shorter prefixes… > I have changed the documentation prefixes, I think we do not need shorter prefixes in these examples. Thanks. > >>> For the purposes of this example, this prefix and no >>> covering aggregate is present in the global routing system. >> Editorial issue: Shouldn't this be "... neither this prefix or any covering aggregate are present ...". The way that you have written it now had me confused for a moment, thinking that this prefix is present but no covering prefix is present. I don't think that is what you mean. >> > Yes good catch, fixed. > >>> 6. LISP-NAT >>> >>> >>> >> Technical issue: Section 6 should probably point to some BEHAVE WG RFCs on how the NAT operation should technically work. > Ok I will added > >>> An example of this translation follows. For this example, a site has >>> been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize >>> LISP-NAT, the site has also been provided the PA EID of >>> 128.200.1.0/24, and uses the first address (128.200.1.1) as the >>> site's RLOC. The rest of this PA space (128.200.1.2 to >>> 128.200.1.254) is used as a translation pool for this site's hosts >>> who need to send packets to non-LISP hosts. >>> >> Editorial issue: Please use the officially allocated example addresses. >> > Fixed. > > >>> 6.4. LISP-NAT and multiple EIDs >>> >>> >>> >>> When a site has two addresses that a host might use for global >>> reachability, care must be chosen on which EID is found in DNS. For >>> example, whether applications such as DNS use the LISP-R EID or the >>> LISP-NR EID. This problem exists for NAT in general, but the >>> specific issue described above is unique to LISP. Using PITRs can >>> mitigate this problem, since the LISP-NR EID can be reached in all >>> cases. >> Technical issue: but if you had a PITR, you would not need LISP-NAT, or am I missing something? > I agree (which you below) that Section 6.4 is redundant with 6.5, since 6.5 is more clearer and more complete and I suggest keeping it and removing the above. > >>> 6.5. When LISP-NAT and PITRs used by the same LISP Site >>> >>> >>> >>> With LISP-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 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 >>> general, but the specific issue described above is unique 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, >>> using PITRs can mitigate this problem, because the LISP-NR EID can be >>> reached in all cases. >> Editorial issue: what's the difference between Sections 6.4 and 6.5? It seems that they both talk about the problem of two addresses in a name mapping system. >> >> Technical issue: I don't think "introduces complexity for the site" begins to explain the type of problems caused by having to separate naming systems from each other. Please expand or otherwise highlight that this approach is problematic. > I agree that the problems here deserve further highlighting. I suggest adding the following changes to section 6.5. > >>> 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) >>> >>> >>> >>> 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 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 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. >>> >> Technical issue: This paragraph and Setion 8 in general would greatly from a discussion of the tradeoffs involved in these three mechanisms. Just one downside, stretch, is mentioned above. But I think there are others... impacts to naming systems, asymmetric traffic, etc. Please expand. > I > >>> 9. Security Considerations >> Technical issue: This section seems a bit thin. I'd love to see a discussion of the following additional issues: >> >> Implications to firewalls? Are there any? What about asymmetric routing? > I don't now of any implications to firewalls, asymmetric routing is problematic for any multi-homed site and its my belief that LISP-Interworking has no impact on this beyond what LISP introduces with multihoming. That is, if you multi-home today (with LISP or BGP) you get the possibility of asymmetric flows. Interworking's schemes, by themselves, don't seem to me to change that. However, if you can suggest some specific examples to guide this discussion I'll be happy to produce some text, I just can't think of anything right now. What you say above would also be good text to add, IMO. That is, lack of an impact is also useful information. > >> Are there Denial-of-service attacks on PITRs and PETRs? > From the perspective of general Interworking, this is no different than ITRs or ETRs, as far as I can see. The LISP Deployment draft might benefit from some discussion here (due to placement in the network topology etc). Based on your note below I will add a reference to the base spec for this. OK > >> Are there DNSSEC implications on the naming system implications? > None that I can see, since with LISP-NAT both LISP-R and LISP-NR addresses 'belong' to the same site. (but again if you have some specific guidance here I am open to suggestions). > >>> Like any router or LISP ITR, PITRs 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). >>> >> You should also talk about these devices being trusted to route your traffic to begin with, and how both non-Lisp and Lisp networks should be careful in not peering with untrustworthy networks. > Ok adding some text here. Note that the Deployment draft goes into some more detail about Originating EID-Routes and the impact of SIDR on PITRs. OK > >> This is very similar to, say, peering with someone who says they can reach everything in the Internet but in reality their quality or security leaves something to be desired. > yes good point, and this is unique to interworking (though I can see an analogy to selecting a mapping service provider) > > How about this text for the security considerations section: > > Like any router or LISP ITR, 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. > > 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 to enable Interworking), packets will have the 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 traffic destined to non-LISP > sites to the Proxy-ETR (thus ensuring the outer IP source address is > the site's RLOC). Good. Thanks. > > >> (Of course, all additions to the security considerations text could be pointers elsewhere, if the issues have already been noted in other documents.) > Right I can point to [LISP] for the cases where Proxy-ITRs and Proxy-ETRs are similar to ITRs and ETRs. > > > Thanks again for your careful review! > Thanks, Jari From jari.arkko@piuha.net Mon Feb 6 06:44:07 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA721F8652 for ; Mon, 6 Feb 2012 06:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM3JNpOSTU3o for ; Mon, 6 Feb 2012 06:44:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0CADD21F85CF for ; Mon, 6 Feb 2012 06:44:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5D6EA2DA06; Mon, 6 Feb 2012 16:44:04 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIwzXIWYB_vb; Mon, 6 Feb 2012 16:44:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 70B5B2CC39; Mon, 6 Feb 2012 16:44:03 +0200 (EET) Message-ID: <4F2FE732.20703@piuha.net> Date: Mon, 06 Feb 2012 16:44:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4F017880.3060500@piuha.net> <4F2C290B.7040603@joelhalpern.com> <8531F9A6-AC66-4265-A3E3-EFD6F9F7B09C@cisco.com> <4F2C401E.7020203@joelhalpern.com> In-Reply-To: <4F2C401E.7020203@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:44:07 -0000 That also works for me. Jari On 03.02.2012 22:14, Joel M. Halpern wrote: > Removing option 1 would solve my concern very nicely. Thanks. > Joel > > On 2/3/2012 3:10 PM, Darrel Lewis wrote: >> >> On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote: >> >>> I am a bit concerned that the description of the cases does not work. >>> In particular, if I am reading the text (preserved below) properly, it says that the ITR can use the presence of a covering prefix in the regular BGP table to tell that a destination is a non-LISP destination. >>> But in order for interworking to function, all LISP EIDs must fall into prefixes which are advertised into the regular BGP routing table by PITRs somewhere. As such, it seems that decision process 1 below would be counter-productive, sending all LISP-LISP traffic through PITRs. >>> >>> Since I know that what I am inferring is not what you intend, we need better text please. >>> >> >> Good point Joel, I think the text confuses the issue. At this point the right way for a device to determine if the destination is LISP is to _look into the mapping system_ not the DFZ. How about simply removing the first numbered bullet, and adjusting the text? >> >> I also noticed that I didn't provide in response to Jari on Section 8. (though i right now I am at a loss for exactly what text to include I will think about it. and reply this weekend. >> >> -D >> >>> Yours, >>> Joel >>> >>> On 2/3/2012 1:21 PM, Darrel Lewis wrote: >>>> Yes this is a good suggestion. Interworking pre-dated negative map-replies so the text hear isn't as clear as it should be. How about: >>>> >>>> >>>> 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 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. This can be achieved >>>> by using one of two mechanisms: >>>> >>>> 1. At the ITR in the source site, if the destination of an IP packet >>>> is found to match a prefix from the BGP routing table, then the >>>> site is directly reachable by the BGP core as it exists and >>>> operates today. >>>> >>>> 2. 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 are some situations where (un-encapsulated) packets originated by a >>>> LISP site may not get forwarded successfully to a non-LISP site. >>>> These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers). >> >> > From darlewis@cisco.com Mon Feb 6 08:45:41 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A90A21F869C for ; Mon, 6 Feb 2012 08:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G4h6u2BgsXY for ; Mon, 6 Feb 2012 08:45:40 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD1B521F869A for ; Mon, 6 Feb 2012 08:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=4009; q=dns/txt; s=iport; t=1328546740; x=1329756340; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vQCYjBPU1og8ddCpqgTo+LPJIEZZQZ6oQODYiFk+MzM=; b=gRbWOYn+M/kuo3srRTGEZ9800KbuRo9JnA2sX8wO0R4AIOIi1yc++Zuc e83rSq+1VGrSYZuGPA1OEMMcnPSm4i5FPAgot/6nTDulVLZkFBpBoPGWC 0YTxMrdI1z3TNY5/uKYMtq7hLGz+GH3Pbd76mc6QEmz+1NW6xYsJ69IvD U=; X-IronPort-AV: E=Sophos;i="4.73,371,1325462400"; d="scan'208";a="28920923" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Feb 2012 16:45:40 +0000 Received: from sjc-vpn3-545.cisco.com (sjc-vpn3-545.cisco.com [10.21.66.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q16GjdvJ024691; Mon, 6 Feb 2012 16:45:39 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Darrel Lewis In-Reply-To: <4F2FE70E.6080005@piuha.net> Date: Mon, 6 Feb 2012 08:45:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC917B5-15C5-4270-A22E-D2483D045CBA@cisco.com> References: <4F017880.3060500@piuha.net> <4F2FE70E.6080005@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 16:45:41 -0000 On Feb 6, 2012, at 6:43 AM, Jari Arkko wrote: > On 03.02.2012 20:21, Darrel Lewis wrote: >> Jari, >>=20 >> Sorry for taking so long to respond to your review. Please find = suggested text below as well as a proposed -03 draft attached. >>=20 >> On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote: >>=20 >>> I have reviewed this document. >>>=20 >>> In general, it is well written and almost ready to go forward. There = are a couple of areas that need further text, however. The main issue is = a clear description of the to-experiment and problematic areas of LISP = interworking. (Making those is also needed in order to get the document = approved, based on experience of taking the other Lisp documents to the = IESG.) Another issue is that I think the security considerations text = needs work. >>>=20 >>> In moder detail: >>>=20 >>> Technical issue: As with the other documents from the group, Section = 1 should include a high-level explanation of what issues are uncertain, = potentially problematic, or worth experimenting on. For instance, I = presume you should say something about the effects of having to NAT = traffic, finding deployment motivations to set up proxy ITRs, possible = inclusion of too much non-aggregated EID space in the DFZ, effects of = the asymmetric PITR routing, and so on. >>>=20 >>> Please suggest text. >> I suggest adding the following paragraph to the end of the = Introduction (Section 1). >>=20 >> Several areas concerning the Interworking of LISP and non-LISP = sites remain open >> for further study. These areas include an examination the impact = of LISP-NAT on >> internet traffic and applications, understanding the deployment = motivations for >> the deployment and operation of Proxy Tunnel Routers, the impact = of EID routes >> originated by these Proxy Tunnel Routers into the Internet's = Default Free Zone, >> and the effects of Proxy Tunnel Routers on internet traffic and = applications. >> of Proxy Tunnel Routers on internet traffic and applications. = This analysis will >> explain what role Proxy Tunnel Routers and NAT will play in the = expected ongoing >> presence of both LISP and non-LISP sites in the Internet. >=20 >=20 > Some duplication above ("of Proxy ....") Ack. >=20 > I like the beginning part, but I would replace the last sentence with: >=20 > "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." >=20 > (I think that is a true statement. And I'm not trying to be negative, = but from processing the other docs in the IESG, it is clear that we = cannot get the documents approved without safety warnings like this.) I'm fine with this text Jari, consider it changed. >>=20 >>=20 >>>> 9. Security Considerations >>> Technical issue: This section seems a bit thin. I'd love to see a = discussion of the following additional issues: >>>=20 >>> Implications to firewalls? Are there any? What about asymmetric = routing? >> I don't now of any implications to firewalls, asymmetric routing is = problematic for any multi-homed site and its my belief that = LISP-Interworking has no impact on this beyond what LISP introduces with = multihoming. That is, if you multi-home today (with LISP or BGP) you = get the possibility of asymmetric flows. Interworking's schemes, by = themselves, don't seem to me to change that. However, if you can = suggest some specific examples to guide this discussion I'll be happy to = produce some text, I just can't think of anything right now. >=20 > What you say above would also be good text to add, IMO. That is, lack = of an impact is also useful information. Ok thanks for the guidance will suggest text for you here. It seems like = we are in agreement. I will make these changes and post the -03 = version. -Darrel From internet-drafts@ietf.org Tue Feb 7 01:12:11 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914E221F86EE; Tue, 7 Feb 2012 01:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoIArrVMIxJA; Tue, 7 Feb 2012 01:12:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DFD21F86DB; Tue, 7 Feb 2012 01:12:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120207091211.25698.88698.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 01:12:11 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-21.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 09:12:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-21.txt Pages : 97 Date : 2012-02-07 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-21.txt From internet-drafts@ietf.org Tue Feb 7 01:12:55 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC421F8539; Tue, 7 Feb 2012 01:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSkGOY+YR97x; Tue, 7 Feb 2012 01:12:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F215021F844C; Tue, 7 Feb 2012 01:12:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120207091254.24721.5487.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 01:12:54 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 09:12:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-13.txt Pages : 40 Date : 2012-02-07 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-13.txt From rogerj@gmail.com Tue Feb 7 11:38:00 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76F21F88E2 for ; Tue, 7 Feb 2012 11:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6LWs0V7KJvM for ; Tue, 7 Feb 2012 11:37:59 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2216321F88DC for ; Tue, 7 Feb 2012 11:37:58 -0800 (PST) Received: by lahl5 with SMTP id l5so5130907lah.31 for ; Tue, 07 Feb 2012 11:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vw1qHVHLjPEpKPNojv+yWFcgkgb7QwoG/sB2ePEkKi8=; b=qWFmhZ9BSuh280/TQfpcs84aTp4M/782Zg+cU3LSezDdsM56mRvxio7B4axlznUK9Z bC4BSjJ+9QqTX2/2tYNrrl2pGbbOjxc0YcQltxAoDe/ImXmtcbbuVcKwADQb6DxXuaZ3 GyNUQiyHdoQiMhbOioh079BqMn60N3Ci7CXE0= MIME-Version: 1.0 Received: by 10.112.29.6 with SMTP id f6mr6854886lbh.69.1328643477959; Tue, 07 Feb 2012 11:37:57 -0800 (PST) Received: by 10.112.27.169 with HTTP; Tue, 7 Feb 2012 11:37:57 -0800 (PST) In-Reply-To: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> References: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> Date: Tue, 7 Feb 2012 20:37:57 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: luigi@net.t-labs.tu-berlin.de, Darrel Lewis , dmm@cisco.com, vaf@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , lisp@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:38:00 -0000 Is this draft to be considered dead in the water or are there still thought going into it? We were a few that briefly talked about this in London last week (CiscoLive) and I think we all agree the idea is good. Maybe use something out of the old 6bone alingned space, 3fff::/16? --- Roger J --- On Mon, Oct 31, 2011 at 2:18 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Locator/ID Separation Protocol Work= ing Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : LISP EID Block > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Luigi Iannone > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Darrel Lewis > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David Meyer > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vince Fuller > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-lisp-eid-block-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31 > > =A0 This is a direction to IANA to allocate a /16 IPv6 prefix for use > =A0 with the Locator/ID Separation Protocol (LISP). =A0The prefix will be > =A0 used by sites deploying LISP as EID (Endpoint IDentifier) addressing > =A0 space for local intra-domain routing and global endpoint > =A0 identification. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From jmh@joelhalpern.com Tue Feb 7 11:41:07 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D551E11E8088 for ; Tue, 7 Feb 2012 11:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.931 X-Spam-Level: X-Spam-Status: No, score=-101.931 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX8urmPPUW0e for ; Tue, 7 Feb 2012 11:41:07 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8811E8072 for ; Tue, 7 Feb 2012 11:41:07 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 2849DCD226 for ; Tue, 7 Feb 2012 11:41:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EFBEF1BC3099; Tue, 7 Feb 2012 11:41:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-124.clppva.btas.verizon.net [71.161.51.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CD39F1BC3092; Tue, 7 Feb 2012 11:41:05 -0800 (PST) Message-ID: <4F317E50.7010103@joelhalpern.com> Date: Tue, 07 Feb 2012 14:41:04 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= References: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dmm@cisco.com, lisp@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:41:08 -0000 This item is included in the proposed recharter of the WG. I hope to see it produced, and a prefix assigned, in a timely fashion. Yours, joel On 2/7/2012 2:37 PM, Roger Jørgensen wrote: > Is this draft to be considered dead in the water or are there still > thought going into it? > > We were a few that briefly talked about this in London last week > (CiscoLive) and I think we all agree the idea is good. Maybe use > something out of the old 6bone alingned space, 3fff::/16? > > > > --- Roger J --- > > On Mon, Oct 31, 2011 at 2:18 PM, wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. >> >> Title : LISP EID Block >> Author(s) : Luigi Iannone >> Darrel Lewis >> David Meyer >> Vince Fuller >> Filename : draft-ietf-lisp-eid-block-01.txt >> Pages : 10 >> Date : 2011-10-31 >> >> This is a direction to IANA to allocate a /16 IPv6 prefix for use >> with the Locator/ID Separation Protocol (LISP). The prefix will be >> used by sites deploying LISP as EID (Endpoint IDentifier) addressing >> space for local intra-domain routing and global endpoint >> identification. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > > From terry.manderson@icann.org Tue Feb 7 15:36:51 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4021F87A8 for ; Tue, 7 Feb 2012 15:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG21UyZlhw92 for ; Tue, 7 Feb 2012 15:36:50 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id B84B621F870E for ; Tue, 7 Feb 2012 15:36:50 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 7 Feb 2012 15:36:50 -0800 From: Terry Manderson To: Darrel Lewis , Jari Arkko Date: Tue, 7 Feb 2012 15:36:47 -0800 Thread-Topic: [lisp] AD review of draft-ietf-lisp-interworking Thread-Index: Aczk7tEkVmX6Z9KkSVmQx2A6sdpLSQBAoo8Y Message-ID: In-Reply-To: <5DC917B5-15C5-4270-A22E-D2483D045CBA@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-lisp-interworking@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:36:51 -0000 Thanks Dino! T. On 7/02/12 2:45 AM, "Darrel Lewis" wrote: >=20 >=20 > On Feb 6, 2012, at 6:43 AM, Jari Arkko wrote: >=20 >> On 03.02.2012 20:21, Darrel Lewis wrote: >>> Jari, >>>=20 >>> Sorry for taking so long to respond to your review. Please find sugges= ted >>> text below as well as a proposed -03 draft attached. >>>=20 >>> On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote: >>>=20 >>>> I have reviewed this document. >>>>=20 >>>> In general, it is well written and almost ready to go forward. There a= re a >>>> couple of areas that need further text, however. The main issue is a c= lear >>>> description of the to-experiment and problematic areas of LISP >>>> interworking. (Making those is also needed in order to get the documen= t >>>> approved, based on experience of taking the other Lisp documents to th= e >>>> IESG.) Another issue is that I think the security considerations text = needs >>>> work. >>>>=20 >>>> In moder detail: >>>>=20 >>>> Technical issue: As with the other documents from the group, Section 1 >>>> should include a high-level explanation of what issues are uncertain, >>>> potentially problematic, or worth experimenting on. For instance, I pr= esume >>>> you should say something about the effects of having to NAT traffic, >>>> finding deployment motivations to set up proxy ITRs, possible inclusio= n of >>>> too much non-aggregated EID space in the DFZ, effects of the asymmetri= c >>>> PITR routing, and so on. >>>>=20 >>>> Please suggest text. >>> I suggest adding the following paragraph to the end of the Introduction >>> (Section 1). >>>=20 >>> Several areas concerning the Interworking of LISP and non-LISP sites >>> remain open >>> for further study. These areas include an examination the impact of >>> LISP-NAT on >>> internet traffic and applications, understanding the deployment >>> motivations for >>> the deployment and operation of Proxy Tunnel Routers, the impact of = EID >>> routes >>> originated by these Proxy Tunnel Routers into the Internet's Default= Free >>> Zone, >>> and the effects of Proxy Tunnel Routers on internet traffic and >>> applications. >>> of Proxy Tunnel Routers on internet traffic and applications. This >>> analysis will >>> explain what role Proxy Tunnel Routers and NAT will play in the expe= cted >>> ongoing >>> presence of both LISP and non-LISP sites in the Internet. >>=20 >>=20 >> Some duplication above ("of Proxy ....") >=20 > Ack. >=20 >>=20 >> I like the beginning part, but I would replace the last sentence with: >>=20 >> "Until these issues are fully understood, it is possible that the >> interworking mechanisms described in this document are hard to deploy, o= r may >> have unintended consequences to applications." >>=20 >> (I think that is a true statement. And I'm not trying to be negative, bu= t >> from processing the other docs in the IESG, it is clear that we cannot g= et >> the documents approved without safety warnings like this.) >=20 > I'm fine with this text Jari, consider it changed. >=20 > >=20 >>>=20 >>>=20 >>>>> 9. Security Considerations >>>> Technical issue: This section seems a bit thin. I'd love to see a >>>> discussion of the following additional issues: >>>>=20 >>>> Implications to firewalls? Are there any? What about asymmetric routin= g? >>> I don't now of any implications to firewalls, asymmetric routing is >>> problematic for any multi-homed site and its my belief that >>> LISP-Interworking has no impact on this beyond what LISP introduces wit= h >>> multihoming. That is, if you multi-home today (with LISP or BGP) you g= et >>> the possibility of asymmetric flows. Interworking's schemes, by themse= lves, >>> don't seem to me to change that. However, if you can suggest some spec= ific >>> examples to guide this discussion I'll be happy to produce some text, I= just >>> can't think of anything right now. >>=20 >> What you say above would also be good text to add, IMO. That is, lack of= an >> impact is also useful information. >=20 > Ok thanks for the guidance will suggest text for you here. It seems like = we > are in agreement. I will make these changes and post the -03 version. >=20 > -Darrel >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Tue Feb 7 15:39:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F8721F8535 for ; Tue, 7 Feb 2012 15:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQYRHKjWlqoc for ; Tue, 7 Feb 2012 15:39:54 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id D32F721F8526 for ; Tue, 7 Feb 2012 15:39:27 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 7 Feb 2012 15:39:27 -0800 From: Terry Manderson To: Darrel Lewis , Jari Arkko Date: Tue, 7 Feb 2012 15:39:25 -0800 Thread-Topic: [lisp] AD review of draft-ietf-lisp-interworking Thread-Index: Aczk7tEkVmX6Z9KkSVmQx2A6sdpLSQBAoo8YAAAXixQ= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-lisp-interworking@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:39:57 -0000 Sigh.. "Thanks Darrel" dammit. :-( Long night/early morning. Sorry. T. On 8/02/12 9:36 AM, "Terry" wrote: > Thanks Dino! >=20 > T. >=20 >=20 > On 7/02/12 2:45 AM, "Darrel Lewis" wrote: >=20 >>=20 >>=20 >> On Feb 6, 2012, at 6:43 AM, Jari Arkko wrote: >>=20 >>> On 03.02.2012 20:21, Darrel Lewis wrote: >>>> Jari, >>>>=20 >>>> Sorry for taking so long to respond to your review. Please find sugge= sted >>>> text below as well as a proposed -03 draft attached. >>>>=20 >>>> On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote: >>>>=20 >>>>> I have reviewed this document. >>>>>=20 >>>>> In general, it is well written and almost ready to go forward. There = are a >>>>> couple of areas that need further text, however. The main issue is a = clear >>>>> description of the to-experiment and problematic areas of LISP >>>>> interworking. (Making those is also needed in order to get the docume= nt >>>>> approved, based on experience of taking the other Lisp documents to t= he >>>>> IESG.) Another issue is that I think the security considerations text >>>>> needs=20 >>>>> work. >>>>>=20 >>>>> In moder detail: >>>>>=20 >>>>> Technical issue: As with the other documents from the group, Section = 1 >>>>> should include a high-level explanation of what issues are uncertain, >>>>> potentially problematic, or worth experimenting on. For instance, I >>>>> presume=20 >>>>> you should say something about the effects of having to NAT traffic, >>>>> finding deployment motivations to set up proxy ITRs, possible inclusi= on of >>>>> too much non-aggregated EID space in the DFZ, effects of the asymmetr= ic >>>>> PITR routing, and so on. >>>>>=20 >>>>> Please suggest text. >>>> I suggest adding the following paragraph to the end of the Introductio= n >>>> (Section 1). >>>>=20 >>>> Several areas concerning the Interworking of LISP and non-LISP site= s >>>> remain open >>>> for further study. These areas include an examination the impact o= f >>>> LISP-NAT on >>>> internet traffic and applications, understanding the deployment >>>> motivations for >>>> the deployment and operation of Proxy Tunnel Routers, the impact of= EID >>>> routes >>>> originated by these Proxy Tunnel Routers into the Internet's Defaul= t >>>> Free=20 >>>> Zone, >>>> and the effects of Proxy Tunnel Routers on internet traffic and >>>> applications. >>>> of Proxy Tunnel Routers on internet traffic and applications. This >>>> analysis will >>>> explain what role Proxy Tunnel Routers and NAT will play in the exp= ected >>>> ongoing >>>> presence of both LISP and non-LISP sites in the Internet. >>>=20 >>>=20 >>> Some duplication above ("of Proxy ....") >>=20 >> Ack. >>=20 >>>=20 >>> I like the beginning part, but I would replace the last sentence with: >>>=20 >>> "Until these issues are fully understood, it is possible that the >>> interworking mechanisms described in this document are hard to deploy, = or >>> may=20 >>> have unintended consequences to applications." >>>=20 >>> (I think that is a true statement. And I'm not trying to be negative, b= ut >>> from processing the other docs in the IESG, it is clear that we cannot = get >>> the documents approved without safety warnings like this.) >>=20 >> I'm fine with this text Jari, consider it changed. >>=20 >> >>=20 >>>>=20 >>>>=20 >>>>>> 9. Security Considerations >>>>> Technical issue: This section seems a bit thin. I'd love to see a >>>>> discussion of the following additional issues: >>>>>=20 >>>>> Implications to firewalls? Are there any? What about asymmetric routi= ng? >>>> I don't now of any implications to firewalls, asymmetric routing is >>>> problematic for any multi-homed site and its my belief that >>>> LISP-Interworking has no impact on this beyond what LISP introduces wi= th >>>> multihoming. That is, if you multi-home today (with LISP or BGP) you = get >>>> the possibility of asymmetric flows. Interworking's schemes, by >>>> themselves,=20 >>>> don't seem to me to change that. However, if you can suggest some spe= cific >>>> examples to guide this discussion I'll be happy to produce some text, = I >>>> just=20 >>>> can't think of anything right now. >>>=20 >>> What you say above would also be good text to add, IMO. That is, lack o= f an >>> impact is also useful information. >>=20 >> Ok thanks for the guidance will suggest text for you here. It seems like= we >> are in agreement. I will make these changes and post the -03 version. >>=20 >> -Darrel >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Wed Feb 8 00:33:46 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD53B21F86DF for ; Wed, 8 Feb 2012 00:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3Bc6WvBOOuz for ; Wed, 8 Feb 2012 00:33:46 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA2521F86DA for ; Wed, 8 Feb 2012 00:33:46 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (localhost [127.0.0.1]) by filter.mynetwork.local (Postfix) with ESMTP id C57EC4C0348; Wed, 8 Feb 2012 09:33:43 +0100 (CET) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id B7F3F4C0347; Wed, 8 Feb 2012 09:33:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Luigi Iannone In-Reply-To: <4F317E50.7010103@joelhalpern.com> Date: Wed, 8 Feb 2012 09:33:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64333E8F-F36A-4428-B8A1-E1BAD117CE2F@net.t-labs.tu-berlin.de> References: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> <4F317E50.7010103@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1257) Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , dmm@cisco.com, lisp@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 08:33:46 -0000 BTW the draft is not expired, and I plan to give an update during the = next WG meeting. Luigi On Feb 7, 2012, at 20:41 , Joel M. Halpern wrote: > This item is included in the proposed recharter of the WG. > I hope to see it produced, and a prefix assigned, in a timely fashion. > Yours, > joel >=20 > On 2/7/2012 2:37 PM, Roger J=F8rgensen wrote: >> Is this draft to be considered dead in the water or are there still >> thought going into it? >>=20 >> We were a few that briefly talked about this in London last week >> (CiscoLive) and I think we all agree the idea is good. Maybe use >> something out of the old 6bone alingned space, 3fff::/16? >>=20 >>=20 >>=20 >> --- Roger J --- >>=20 >> On Mon, Oct 31, 2011 at 2:18 PM, wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >>>=20 >>> Title : LISP EID Block >>> Author(s) : Luigi Iannone >>> Darrel Lewis >>> David Meyer >>> Vince Fuller >>> Filename : draft-ietf-lisp-eid-block-01.txt >>> Pages : 10 >>> Date : 2011-10-31 >>>=20 >>> This is a direction to IANA to allocate a /16 IPv6 prefix for use >>> with the Locator/ID Separation Protocol (LISP). The prefix will = be >>> used by sites deploying LISP as EID (Endpoint IDentifier) = addressing >>> space for local intra-domain routing and global endpoint >>> identification. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >>=20 >>=20 From internet-drafts@ietf.org Wed Feb 8 04:27:37 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5721F84DC; Wed, 8 Feb 2012 04:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beTv7dK0L2MR; Wed, 8 Feb 2012 04:27:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813321F841E; Wed, 8 Feb 2012 04:27:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120208122735.23361.94972.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 04:27:35 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-14.txt Pages : 40 Date : 2012-02-08 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-14.txt From darlewis@cisco.com Wed Feb 8 05:50:32 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D1E21F85E6 for ; Wed, 8 Feb 2012 05:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.362 X-Spam-Level: X-Spam-Status: No, score=-7.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJxdplzsVKMX for ; Wed, 8 Feb 2012 05:50:26 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E46C521F85C3 for ; Wed, 8 Feb 2012 05:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=101838; q=dns/txt; s=iport; t=1328709017; x=1329918617; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DPyC6/CdrGYtdktCA5K1w6EPh+fWp2SZgg/H1cJdknk=; b=eMaaCNkp4Ye3gyjqChTtNfQ5ryPQ8YhHMlvBFgWQ3Ro9DigM6n09eu1+ fR9q8SrS22GUuBbsAUenJxFSPg6JM9a7qjjl9u9lvmfo5V8AmA6/wPrh6 81LCd+F1f5l015m4+oHWKQgTxJkZV470Wnja+NTewKP7h5EFgYH6yaPCT 4=; X-Files: rfcdiff-draft-ietf-lisp-interowrking-02-to-03.html, draft-ietf-lisp-interworking-03.txt : 50046, 45168 X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="txt'?html'217?scan'217,208,217";a="128852015" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2012 13:50:14 +0000 Received: from dhcp-bdlk10-vlan254-10-147-56-170.cisco.com (dhcp-bdlk10-vlan254-10-147-56-170.cisco.com [10.147.56.170]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q18DoEqg017509; Wed, 8 Feb 2012 13:50:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/mixed; boundary="Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0" From: Darrel Lewis In-Reply-To: <4F2FE732.20703@piuha.net> Date: Wed, 8 Feb 2012 05:50:13 -0800 Message-Id: References: <4F017880.3060500@piuha.net> <4F2C290B.7040603@joelhalpern.com> <8531F9A6-AC66-4265-A3E3-EFD6F9F7B09C@cisco.com> <4F2C401E.7020203@joelhalpern.com> <4F2FE732.20703@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:50:32 -0000 --Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have updated the draft to address the comments received in this = thread, and posted the -03 version. draft-03 and diffs from 02 attached. Thanks again for the careful review and constructive comments! -Darrel --Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0 Content-Disposition: attachment; filename=rfcdiff-draft-ietf-lisp-interowrking-02-to-03.html Content-Type: text/html; name="rfcdiff-draft-ietf-lisp-interowrking-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-interworking-02.txt draft-ietf-lisp-interworking-03.txt 
Network Working Group                                           D. Lewis
Internet-Draft                                                  D. Meyer
Intended status: Experimental                               D. Farinacci
Expires: January 2, August 11, 2012                                       V. Fuller
                                                     Cisco Systems, Inc.
                                                           June 30, 2011
                                                        February 8, 2012

                  Interworking LISP with IPv4 and IPv6
                  draft-ietf-lisp-interworking-02.txt
                  draft-ietf-lisp-interworking-03.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)
   (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 Proxy Egress
   Tunnel Router (PETR) to handle cases where a LISP ITR cannot send
   packets to non-LISP sites without encapsulation.

Status of this Memo

   This Internet-Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is submitted aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in full conformance accordance with the
   provisions Section 6 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 January 2, August 11, 2012.

Copyright Notice

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

1.  Introduction

   This document describes interoperation 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 is
   that EID prefixes are normally not advertised into the Internet's
   Default Free Zone (DFZ).  Specifically, only 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) 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), 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 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

   - Section 6 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 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
   the impact of LISP-NAT on 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 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 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 need not do anything new to
   receive packets.  The only action the LISP site needs (with two
   possible caveats introduced below) to take is to
   know when not to LISP-encapsulate packets.  This can be achieved by using one of two
   mechanisms:

   1.  At the ITR in the source site, if the destination of an IP packet
       is found to match a prefix from the BGP routing table, then the
       site is directly reachable by the BGP core that exists and
       operates today.

   2.  Second, if (from the perspective of the ITR at the source site)
       the packet's destination IP address is not found in the EID-to-
       RLOC mapping database, then the ITR could infer that it is not a
       LISP-capable site.  An ITR can also know knows explicitly
   that the destination is non-LISP if the destination IP address of an
   IP packet matches a
       Negative Map Reply found in its Map Cache.

   3.  In either of (negative) Map-Cache entry which has the two exceptions mentioned above there 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 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) 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

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

   LISP Non-Routable (LISP-NR) Site:  A LISP site whose addresses are
      EIDs only, these EIDs are not found in the legacy Internet routing
      table.

   LISP Proxy Ingress Tunnel Router (PITR):  PITRs are used to provide
      interconnectivity between sites which use LISP EIDs and those
      which do not.  They act as gateways between those parts of the
      Internet which are not using LISP (the legacy Internet) A given
      PITR advertises one or more highly aggregated EID prefixes into
      the public Internet and acts as the ITR for traffic received from
      the public Internet.  LISP Proxy Ingress Tunnel Routers are
      described in Section 5.

   LISP Network Address Translation (LISP-NAT):  Network Address
      Translation between EID space assigned to 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 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 to EID space without changing its existing routing
   policy.

4.2.  Requirement for using BGP

   Non-LISP sites today use BGP to, among other things, enable ingress
   traffic engineering.  Relaxing this requirement 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 Tunnel Router, an approach
       that provides ITR functionality to bridge LISP-capable and non-
       LISP-capable sites.

   2.  Section 6 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 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 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 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 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) allow for non-LISP sites to send
   packets to LISP-NR sites.  A PITR is a new network element that
   shares many characteristics with the LISP ITR.  PITRs allow non-LISP
   sites to send packets to LISP-NR sites without any changes to
   protocols or equipment at the non-LISP site.  PITRs have two primary
   functions:

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

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

5.1.  PITR EID announcements

   A key part of PITR functionality is to advertise routes for highly-
   aggregated EID prefixes into part of the global routing system.
   Aggressive aggregation is performed to minimize the number of new
   announced routes.  In addition, careful placement of PITRs can
   greatly reduce the advertised scope of these new routes.  To this
   end, PITRs 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.

5.2.  Packet Flow with PITRs

   What follows is an example of the path a packet would take when using
   a PITR.  In this example, the LISP-NR site is given the EID prefix
   240.0.0.0/24.
   192.0.2.0/24.  For the purposes of this example, neither this prefix and no
   or any covering aggregate is are present in the global routing system.
   In other words, without the Proxy-ITR announcing 240.0.0.0/24, 192.0.2.0/24, 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
       240.1.1.1
       192.0.2.1 in return.

   2.  The source host has a default route to 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 route to 240.0.0.0/24 192.0.2.0/24 and the next hop is the PITR.

   5.  The PITR has or acquires a mapping for 240.1.1.1 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
       RLOC.

   6.  The PITR 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
       240.1.1.1
       192.0.2.1 host in the destination LISP site.

   8.  Packets from host 240.1.1.1 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 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.  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 to be
   relatively simple - it will only have to encapsulate LISP packets.

5.3.  Scaling PITRs

   PITRs 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 to prevent it from receiving more traffic than it can handle:

   1.  The PITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that PITR.  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 in order to
       share the traffic using IP Anycast.  The asymmetric nature of
       traffic flows through the Proxy ITR means that operationally,
       deploying a set PITRs would be very similar to existing Anycasted
       services like DNS caches.  Multiple 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 placement in the network

   There are several approaches that a network could take in placing
   PITRs.  Placing the PITR 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 CRIO [CRIO], have suggested grouping
   PITRs 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

   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 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-
   LISP sites and LISP-NR sites by ensuring that the LISP-NR's site
   addresses are always routable.  LISP-NAT accomplishes this by
   translating a host's source address from an 'inner' (LISP-NR EID)
   value to an 'outer' (LISP-R) value and keeping this translation in a
   table that it can reference for subsequent packets.

   In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to
   talk 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 packets to return to the site.

   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 sites that use RFC 1918 private EIDs speaking 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 a site is announcing its
   prefix into both the LISP mapping system as well as the Internet DFZ.
   This is because the LISP-R source's address is routable, and return
   packets will be able to natively reach the site.

6.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
   hosts by translating the LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be a either a PI or PA
   address.

   An example of this translation follows.  For this example, a site has
   been assigned a LISP-NR EID of 220.1.1.0/24.  In order to utilize
   LISP-NAT, the site has also been provided the PA EID of
   128.200.1.0/24, and uses the first address (128.200.1.1) as the
   site's RLOC.  The rest of this PA space (128.200.1.2 to
   128.200.1.254) is used as a translation pool for this site's hosts
   who need to 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
          ==============================================================
          220.1.1.0/24   128.200.1.0/24  128.200.1.1    128.200.1.2-254

                    Figure 1: Example Translation Table

   The Host 220.1.1.2 sends a packet (which, for the purposes of this
   example is destined for a non-LISP site) to its default route (the
   ITR).  The ITR receives the packet, and determines that the
   destination is not a LISP site.  How the ITR makes this determination
   is up to 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 220.1.1.2
   to 128.200.1.2, which is the first available address in the LISP-R
   EID space available to it.  The ITR keeps this translation in a table
   in order to reverse this process when receiving packets destined to
   128.200.1.2.

   Finally, when the ITR forwards this packet without encapsulating it,
   it uses the entry in its LISP-NAT table to translate the returning
   packets' destination IPs to the proper host.

6.2.  LISP Sites 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, the LISP-NAT implementation acts much like
   an existing IPv4 NAT device.  The ITR providing the NAT service must
   use LISP-R EIDs for its global address pool as well as providing all
   the standard NAT functions required today.

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

6.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 a LISP EID.  After
   translation, the communication between source and destination ITR and
   ETRs continues as described in [LISP].

   An example of this translation and encapsulation follows.  For this
   example, a host has been assigned a RFC 1918 address of 192.168.1.2.
   In order to utilize LISP-NAT, the site also has been provided the
   LISP-R EID prefix of 192.0.2.0/24, and 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 used as a translation pool for this site's hosts
   who need to send packets to both non-LISP and LISP hosts.

   The Host 192.168.1.2 sends a packet destined for a non-LISP site to
   its default route (the ITR).  The ITR receives the packet and
   determines that the destination is a LISP site.  How the ITR makes
   this determination is up 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 this packet (see [LISP] for details).
   The ITR uses the site's RLOC as the LISP outer header's source and
   the translation address 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 and
   then forward to the proper host.

6.4.  LISP-NAT and multiple EIDs

   When a site has two addresses that a host might use for global
   reachability, care must be chosen on which EID is found in DNS.  For
   example, whether applications such as DNS use the LISP-R EID or the
   LISP-NR EID.  This problem exists for NAT in general, but the
   specific issue described above is unique to LISP.  Using PITRs can
   mitigate this problem, since the LISP-NR EID can be reached in all
   cases.

6.5.  When LISP-NAT and PITRs used by the same LISP Site

   With LISP-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 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
   general, but the specific issue described above is unique 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,
   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 LISP sites to send
   packets to non-LISP sites 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 a new network element that,
   conceptually, acts as an ETR for traffic destined to non-LISP sites.
   This also has 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) and these would be routed directly to the
   corespondent site's ETR.  All other packets (those destined to non-
   LISP sites) will be sent to the originating site's PETR.

   There are two primary reasons why sites would want to utilize a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks. (see section 9)

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where some of the intermediate network
      does not support the particular IP protocol desired (v4 or v6).
      PETRs can allow this LISP site's data to 'hop over' this by
      utilizing LISP's support 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 the aid of a
   Proxy-ETR (or PETR).  An ITR is simply configured to send all non-
   LISP traffic, which it normally would have forwarded natively (non-
   encapsulated), to a PETR.  In the case where the ITR uses a Map-
   Resolver(s), the ITR will encapsulate packets that match the received
   Negative Map-Cache to the configured Proxy-ETR(s).  In the case where
   the ITR is connected to the mapping system 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 use the LISP (outer) header's destination address to route the
   packets toward the configured Proxy-ETR.

   A PETR should verify the (inner) source EID of the packet at time of
   decapsulation in order to verify that this is from a configured LISP
   site.  This is to prevent spoofed inner sources from being
   encapsulated through the Proxy-ETR.

   What follows is an example of the path a packet would take when using
   a PETR.  In this example, the LISP-NR (or LISP-R) site is given the
   EID prefix 240.2.0.0/24, 192.0.2.0/24, and it is trying to reach host at a non-LISP
   site with the IP prefix of 192.0.2.0/24. 198.51.100.0/24.  For the purposes of this
   example, the destination is a non-LISP site and 192.0.2.0/24 (198.51.100.0/24) is found in the Internet's
   routing system.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup for the destination, and gets
       192.0.2.100
       198.51.100.100 (a Ip address of a host in a the non-LISP site) in
       return.

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

   3.  The CE is a LISP ITR, and is configured to encapsulate traffic
       destined for non-LISP sites to a Proxy-ETR.

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

   5.  The packet is then routed natively and directly to the
       destination (non-LISP) site 192.0.2.0/24. 198.51.100.0/24.

   Note that in this 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.

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

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

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) and Proxy-ETRs (PETRs) 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, PITRs 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 to enable Interworking), packets will have the 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 traffic destined to 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
   [RFC2434].

12.  References

12.1.  Normative References

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

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

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-09.txt
              draft-ietf-lisp-ms-15.txt (work in progress), June 2011.
              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.

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

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

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

   [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

Full Copyright Statement

   Copyright (C) The IETF Trust (2012).

   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.
--Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0 Content-Disposition: attachment; filename=draft-ietf-lisp-interworking-03.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-interworking-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Lewis Internet-Draft D. Meyer Intended status: Experimental D. Farinacci Expires: August 11, 2012 V. Fuller Cisco Systems, Inc. February 8, 2012 Interworking LISP with IPv4 and IPv6 draft-ietf-lisp-interworking-03.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) (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 Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. 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). 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 Lewis, et al. Expires August 11, 2012 [Page 1] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 material or to cite them other than as "work in progress." This Internet-Draft will expire on August 11, 2012. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 7 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 7 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 7 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 7 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 9 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 9 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 9 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Impact of the PITRs placement in the network . . . . . . . 11 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 11 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 12 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 13 6.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets to Other LISP Sites . . . . . . . . . . . 13 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 14 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 15 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 15 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Lewis, et al. Expires August 11, 2012 [Page 2] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 1. Introduction This document describes interoperation 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 is that EID prefixes are normally not advertised into the Internet's Default Free Zone (DFZ). Specifically, only 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) 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), 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 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 - Section 6 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 Lewis, et al. Expires August 11, 2012 [Page 3] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 - Section 8 describes the relationship between asymmetric and 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 the impact of LISP-NAT on 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 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. Lewis, et al. Expires August 11, 2012 [Page 4] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 2. 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 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 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) and Section 6 (LISP-NAT) describe two such mechanisms. Case 4 also applies to packets returning to the LISP site, in Case 3. Lewis, et al. Expires August 11, 2012 [Page 5] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 3. Definition of Terms LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only, these EIDs are not found in the legacy Internet routing table. LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide interconnectivity between sites which use LISP EIDs and those which do not. They act as gateways between those parts of the Internet which are not using LISP (the legacy Internet) A given PITR advertises one or more highly aggregated EID prefixes into the public Internet and acts as the ITR for traffic received from the public Internet. LISP Proxy Ingress Tunnel Routers are described in Section 5. LISP Network Address Translation (LISP-NAT): Network Address Translation between EID space assigned to 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 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]. Lewis, et al. Expires August 11, 2012 [Page 6] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 to EID space without changing its existing routing policy. 4.2. Requirement for using BGP Non-LISP sites today use BGP to, among other things, enable ingress traffic engineering. Relaxing this requirement 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 Tunnel Router, an approach that provides ITR functionality to bridge LISP-capable and non- LISP-capable sites. 2. Section 6 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 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. Lewis, et al. Expires August 11, 2012 [Page 7] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 That being said, 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 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 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. Lewis, et al. Expires August 11, 2012 [Page 8] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 5. Proxy Ingress Tunnel Routers Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send packets to LISP-NR sites. A PITR is a new network element that shares many characteristics with the LISP ITR. PITRs allow non-LISP sites to send packets to LISP-NR sites without any changes to protocols or equipment at the non-LISP site. PITRs have two primary functions: Originating EID Advertisements: PITRs advertise highly aggregated EID-prefix space on behalf of LISP sites to so that non-LISP sites can reach them. Encapsulating Legacy Internet Traffic: PITRs also encapsulate non- LISP Internet traffic into LISP packets and route them towards their destination RLOCs. 5.1. PITR EID announcements A key part of PITR functionality is to advertise routes for highly- aggregated EID prefixes into part of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of PITRs can greatly reduce the advertised scope of these new routes. To this end, PITRs 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. 5.2. Packet Flow with PITRs What follows is an example of the path a packet would take when using a PITR. 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 any covering aggregate are present in the global routing system. In other words, without the Proxy-ITR announcing 192.0.2.0/24, 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 Edge (CE) router and forwards the packet to the CE. Lewis, et al. Expires August 11, 2012 [Page 9] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 3. The CE has a default route to its Provider Edge (PE) router, and forwards the packet to the PE. 4. The PE has route to 192.0.2.0/24 and the next hop is the PITR. 5. The PITR 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 RLOC. 6. The PITR 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 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. 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 to be relatively simple - it will only have to encapsulate LISP packets. 5.3. Scaling PITRs PITRs 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 to prevent it from receiving more traffic than it can handle: 1. The PITR's aggregate routes might be selectively announced, giving a coarse way to control the quantity of traffic attracted by that PITR. For example, some of the routes being announced might be tagged with a BGP community and their scope of Lewis, et al. Expires August 11, 2012 [Page 10] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 announcement limited by the routing policy of the provider. 2. The same address might be announced by multiple PITRs in order to share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy ITR means that operationally, deploying a set PITRs would be very similar to existing Anycasted services like DNS caches. Multiple 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 placement in the network There are several approaches that a network could take in placing PITRs. Placing the PITR 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 CRIO [CRIO], have suggested grouping PITRs 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 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 may attract more traffic, and therefore more revenue, from their customers. Lewis, et al. Expires August 11, 2012 [Page 11] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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- LISP sites and LISP-NR sites by ensuring that the LISP-NR's site addresses are always routable. LISP-NAT accomplishes this by translating a host's source address from an 'inner' (LISP-NR EID) value to an 'outer' (LISP-R) value and keeping this translation in a table that it can reference for subsequent packets. In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk 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 packets to return to the site. 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 sites that use RFC 1918 private EIDs speaking 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 a site is announcing its prefix into both the LISP mapping system as well as the Internet DFZ. This is because the LISP-R source's address is routable, and return packets will be able to natively reach the site. 6.1. Using LISP-NAT with LISP-NR EIDs LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). This globally unique address may be a either a PI or PA address. An example of this translation follows. For this example, a site has been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize LISP-NAT, the site has also been provided the PA EID of 128.200.1.0/24, and uses the first address (128.200.1.1) as the site's RLOC. The rest of this PA space (128.200.1.2 to 128.200.1.254) is used as a translation pool for this site's hosts who need to send packets to non-LISP hosts. The translation table might look like the following: Lewis, et al. Expires August 11, 2012 [Page 12] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 Site NR-EID Site R-EID Site's RLOC Translation Pool =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254 Figure 1: Example Translation Table The Host 220.1.1.2 sends a packet (which, for the purposes of this example is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet, and determines that the destination is not a LISP site. How the ITR makes this determination is up to 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 220.1.1.2 to 128.200.1.2, which is the first available address in the LISP-R EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 128.200.1.2. Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the returning packets' destination IPs to the proper host. 6.2. LISP Sites 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, the LISP-NAT implementation acts much like an existing IPv4 NAT device. The ITR providing the NAT service must use LISP-R EIDs for its global address pool as well as providing all the standard NAT functions required today. The source of the packet must be translated to a LISP-R EID in a manner similar to Section 6, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation. 6.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 a LISP EID. After translation, the communication between source and destination ITR and ETRs continues as described in [LISP]. An example of this translation and encapsulation follows. For this example, a host has been assigned a RFC 1918 address of 192.168.1.2. In order to utilize LISP-NAT, the site also has been provided the LISP-R EID prefix of 192.0.2.0/24, and uses the first address Lewis, et al. Expires August 11, 2012 [Page 13] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 (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 used as a translation pool for this site's hosts who need to send packets to both non-LISP and LISP hosts. The Host 192.168.1.2 sends a packet destined for a non-LISP site to its default route (the ITR). The ITR receives the packet and determines that the destination is a LISP site. How the ITR makes this determination is up 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 this packet (see [LISP] for details). The ITR uses the site's RLOC as the LISP outer header's source and the translation address 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 and then forward to the proper host. 6.4. LISP-NAT and multiple EIDs With LISP-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 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 general, but the specific issue described above is unique 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, using PITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases. Lewis, et al. Expires August 11, 2012 [Page 14] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 7. Proxy Egress Tunnel Routers Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send packets to non-LISP sites 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 a new network element that, conceptually, acts as an ETR for traffic destined to non-LISP sites. This also has 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) and these would be routed directly to the corespondent site's ETR. All other packets (those destined to non- LISP sites) will be sent to the originating site's PETR. There are two primary reasons why sites would want to utilize a PETR: Avoiding strict uRPF failures: Some provider's access networks require the source of the packets emitted to be within the addressing scope of the access networks. (see section 9) Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where some of the intermediate network does not support the particular IP protocol desired (v4 or v6). PETRs can allow this LISP site's data to 'hop over' this by utilizing LISP's support 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 the aid of a Proxy-ETR (or PETR). An ITR is simply configured to send all non- LISP traffic, which it normally would have forwarded natively (non- encapsulated), to a PETR. In the case where the ITR uses a Map- Resolver(s), the ITR will encapsulate packets that match the received Negative Map-Cache to the configured Proxy-ETR(s). In the case where the ITR is connected to the mapping system 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 use the LISP (outer) header's destination address to route the packets toward the configured Proxy-ETR. A PETR should verify the (inner) source EID of the packet at time of decapsulation in order to verify that this is from a configured LISP site. This is to prevent spoofed inner sources from being encapsulated through the Proxy-ETR. What follows is an example of the path a packet would take when using a PETR. In this example, the LISP-NR (or LISP-R) site is given the Lewis, et al. Expires August 11, 2012 [Page 15] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP site with the IP prefix of 198.51.100.0/24. For the purposes of this example, the destination (198.51.100.0/24) is found in the Internet's routing system. A full protocol exchange example follows: 1. The source host makes a DNS lookup for the destination, and gets 198.51.100.100 (a Ip address of a host in the non-LISP site) in return. 2. The source host has a default route to customer Edge (CE) router and forwards the packet towards the CE. 3. The CE is a LISP ITR, and is configured to encapsulate traffic destined for non-LISP sites to a Proxy-ETR. 4. The Proxy ETR decapsulates the LISP packet and forwards the original packet to its next hop. 5. The packet is then routed natively and directly to the destination (non-LISP) site 198.51.100.0/24. Note that in this 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. Lewis, et al. Expires August 11, 2012 [Page 16] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) 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 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 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. 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) and Proxy-ETRs (PETRs) 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. Lewis, et al. Expires August 11, 2012 [Page 17] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 9. Security Considerations Like any router or LISP ITR, 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 to enable Interworking), packets will have the 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 traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring the outer IP source address is the site's RLOC). Lewis, et al. Expires August 11, 2012 [Page 18] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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. Lewis, et al. Expires August 11, 2012 [Page 19] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 11. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. Lewis, et al. Expires August 11, 2012 [Page 20] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, Lewis, et al. Expires August 11, 2012 [Page 21] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. Lewis, et al. Expires August 11, 2012 [Page 22] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 Lewis, et al. Expires August 11, 2012 [Page 23] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 Full Copyright Statement Copyright (C) The IETF Trust (2012). 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. Lewis, et al. Expires August 11, 2012 [Page 24] =0C --Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 6, 2012, at 6:44 AM, Jari Arkko wrote: > That also works for me. >=20 > Jari >=20 > On 03.02.2012 22:14, Joel M. Halpern wrote: >> Removing option 1 would solve my concern very nicely. Thanks. >> Joel >>=20 >> On 2/3/2012 3:10 PM, Darrel Lewis wrote: >>>=20 >>> On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote: >>>=20 >>>> I am a bit concerned that the description of the cases does not = work. >>>> In particular, if I am reading the text (preserved below) properly, = it says that the ITR can use the presence of a covering prefix in the = regular BGP table to tell that a destination is a non-LISP destination. >>>> But in order for interworking to function, all LISP EIDs must fall = into prefixes which are advertised into the regular BGP routing table by = PITRs somewhere. As such, it seems that decision process 1 below would = be counter-productive, sending all LISP-LISP traffic through PITRs. >>>>=20 >>>> Since I know that what I am inferring is not what you intend, we = need better text please. >>>>=20 >>>=20 >>> Good point Joel, I think the text confuses the issue. At this point = the right way for a device to determine if the destination is LISP is to = _look into the mapping system_ not the DFZ. How about simply removing = the first numbered bullet, and adjusting the text? >>>=20 >>> I also noticed that I didn't provide in response to Jari on Section = 8. (though i right now I am at a loss for exactly what text to include = I will think about it. and reply this weekend. >>>=20 >>> -D >>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 2/3/2012 1:21 PM, Darrel Lewis wrote: >>>>> Yes this is a good suggestion. Interworking pre-dated negative = map-replies so the text hear isn't as clear as it should be. How about: >>>>>=20 >>>>>=20 >>>>> 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 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. This can be = achieved >>>>> by using one of two mechanisms: >>>>>=20 >>>>> 1. At the ITR in the source site, if the destination of an IP = packet >>>>> is found to match a prefix from the BGP routing table, then = the >>>>> site is directly reachable by the BGP core as it exists and >>>>> operates today. >>>>>=20 >>>>> 2. 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'. >>>>>=20 >>>>> There are some situations where (un-encapsulated) packets = originated by a >>>>> LISP site may not get forwarded successfully to a non-LISP = site. >>>>> These situations are reviewed in section 7, (Proxy-Egress = Tunnel Routers). >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_38301E96-19A6-44B2-89D0-BA21165360B0-- From terry.manderson@icann.org Wed Feb 8 22:25:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669521F84EC for ; Wed, 8 Feb 2012 22:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBclzGrYw8vJ for ; Wed, 8 Feb 2012 22:25:34 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5E21F84B4 for ; Wed, 8 Feb 2012 22:25:34 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 8 Feb 2012 22:25:33 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Wed, 8 Feb 2012 22:25:31 -0800 Thread-Topic: Important dates for IETF-83 Paris. Thread-Index: Aczm858++P0KuqmPlESBX78j3TGYfQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Important dates for IETF-83 Paris. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 06:25:35 -0000 Hi Folks, Although we are a few weeks away from the key participant's dates for ietf, I thought I would draw your attention to the list below. The Working group WILL be having a session in Paris, so now is a good time to start considering the important dates. * 2012-02-23 (Thursday): Preliminary agenda published for comment. * 2012-02-27 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -8). * 2012-03-02 (Friday): Final agenda to be published. * 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool. * 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID Submission Tool. * 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool. * 2012-03-16 (Friday): Early Bird registration and payment cut-off at 17:00 PT (UTC -7). * 2012-03-19 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool. * 2012-03-19 (Monday): Registration cancellation cut-off at 17:00 PT (UTC -7). * 2012-03-23 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. So I have time to process agenda requests - I would like to hear from those of you who would like some session time from now until 9/03/2012. This give= s you ample time to do any -00 submissions (note the date above) and let me know if you wish to present to the WG. Cheers Terry From internet-drafts@ietf.org Thu Feb 9 02:23:51 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949D621F86D6; Thu, 9 Feb 2012 02:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqtls1ZzjnHL; Thu, 9 Feb 2012 02:23:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C4821F8664; Thu, 9 Feb 2012 02:23:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209102331.8260.86677.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 02:23:31 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 10:23:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : Darrel Lewis David Meyer Dino Farinacci Vince Fuller Filename : draft-ietf-lisp-interworking-03.txt Pages : 24 Date : 2012-02-09 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) (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 Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-03.txt From iesg-secretary@ietf.org Thu Feb 9 06:48:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0221F871A; Thu, 9 Feb 2012 06:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spExfzDpS9ya; Thu, 9 Feb 2012 06:48:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D595921F85C5; Thu, 9 Feb 2012 06:48:44 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209144844.14814.18911.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 06:48:44 -0800 Cc: lisp@ietf.org Subject: [lisp] Last Call: (Interworking LISP with IPv4 and IPv6) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 14:48:45 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'Interworking LISP with IPv4 and IPv6' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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) (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 Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-interworking/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-interworking/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Feb 9 06:51:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC05B21F872A; Thu, 9 Feb 2012 06:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s39ZZ1K0irIF; Thu, 9 Feb 2012 06:51:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FC21F872B; Thu, 9 Feb 2012 06:51:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209145132.15845.5747.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 06:51:32 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP for Multicast Environments' to Experimental RFC (draft-ietf-lisp-multicast-14.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 14:51:34 -0000 The IESG has approved the following document: - 'LISP for Multicast Environments' (draft-ietf-lisp-multicast-14.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-multicast/ Technical Summary This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Working Group Summary The working group process for this draft was particularly uneventful. Document Quality This document, as one of the key LISP drafts, has had substantial review and benefits from at least two different code-base implementations. Personnel The Document Shepherd is Wassim Haddad and the responsible Area Director is Jari Arkko. From internet-drafts@ietf.org Sun Feb 12 11:32:55 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E181421F8673; Sun, 12 Feb 2012 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mlj0vfO+8mX; Sun, 12 Feb 2012 11:32:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1A21F8669; Sun, 12 Feb 2012 11:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120212193254.17737.9221.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2012 11:32:54 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-22.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 19:32:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-22.txt Pages : 97 Date : 2012-02-12 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-22.txt From iesg-secretary@ietf.org Mon Feb 13 10:29:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4621F8746; Mon, 13 Feb 2012 10:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVZGy-BfC0CN; Mon, 13 Feb 2012 10:29:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D094921F8770; Mon, 13 Feb 2012 10:29:44 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213182944.27938.70978.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 10:29:44 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'Locator/ID Separation Protocol (LISP)' to Experimental RFC (draft-ietf-lisp-22.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:29:45 -0000 The IESG has approved the following document: - 'Locator/ID Separation Protocol (LISP)' (draft-ietf-lisp-22.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp/ Technical Summary This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering and multi-homing benefits even to early adopters, when there are relatively few LISP-capable sites. Working Group Summary Many of the comments received during last call were complex and difficult for the working group to understand. The working group last call was held open for an extended time to ensure sufficient discussion and sufficient effort to address those objections. The LISP protocol set has been controversial over the course of discussions in the RRG and the WG, but a significant majority of the working group participants and the chairs/ADs believe that this version adequately describes an experimental protocol, with its advantages as well as challenges. Document Quality There are several implementations of LISP in existence. Alia Atlas has done significant review and deserves special mention. Personnel Document Shepherd is Joel Halpern, and the responsible Area Director is Jari Arkko. From internet-drafts@ietf.org Tue Feb 14 01:47:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE921F8480; Tue, 14 Feb 2012 01:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9zyDE7OpMkB; Tue, 14 Feb 2012 01:47:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA821F866D; Tue, 14 Feb 2012 01:47:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214094723.5804.72214.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 01:47:23 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:47:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map-Versioning Author(s) : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-map-versioning-08.txt Pages : 24 Date : 2012-02-14 This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-08.txt From jari.arkko@piuha.net Tue Feb 14 14:14:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411FF21E80C4 for ; Tue, 14 Feb 2012 14:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_SINGLETS=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WQuxziF1OAR for ; Tue, 14 Feb 2012 14:14:13 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id F219D21F866E for ; Tue, 14 Feb 2012 14:14:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 085992DA0D for ; Wed, 15 Feb 2012 00:14:10 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFrpxJTVqiYr for ; Wed, 15 Feb 2012 00:14:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 33EC72DA06 for ; Wed, 15 Feb 2012 00:14:08 +0200 (EET) Message-ID: <4F3ADCB0.60800@piuha.net> Date: Wed, 15 Feb 2012 00:14:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: lisp@ietf.org Content-Type: multipart/mixed; boundary="------------030501050705050305070607" Subject: [lisp] base specification, working group charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:14:15 -0000 This is a multi-part message in MIME format. --------------030501050705050305070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have some news for you. The LISP base specification has just been approved yesterday, joining the three other documents from this working group that had already been approved earlier. We'll be working with the remaining two in the coming weeks. The other piece of news is that the IESG has reviewed and discussed your proposed charter, and had a number of suggested changes. The main thrust of the changes is as follows: 1) Cut down the number of items to stay focused; the IESG felt that there was too much material in the proposed charter. 2) Make some items priority 1 deliverables and add some items that are important. The IESG felt that as it had reviewed the base specifications, it now had a good view of what documentation there is on LISP and is still missing. In particular, it was felt that an architecture specification that paints some of the bigger picture would be valuable. Please find attached the proposed charter revision from the IESG along with a diff file to the one that was circulated in the WG list some time ago. We plan to approve this charter in the near future, if you have any objections please bring them up as soon as possible either on the WG mailing list or to iesg@ietf.org Jari --------------030501050705050305070607 Content-Type: text/html; charset=ISO-8859-1; name="charter-new-proposal-from-the-iesg-ver2-from-original-proposal.diff.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="charter-new-proposal-from-the-iesg-ver2-from-original-propos"; filename*1="al.diff.html" Diff: charter-original-proposal.txt - charter-new-proposal-from-the-iesg-ver2.txt
 charter-original-proposal.txt   charter-new-proposal-from-the-iesg-ver2.txt 
Locator/ID Separation Protocol (lisp) Locator/ID Separation Protocol (lisp)
------------------------------------- -------------------------------------
Current Status: Active Current Status: Active
Last updated: 2012-01-19 Last updated: 2012-02-14
Chairs: Chairs:
Joel Halpern <jmh@joelhalpern.com> Joel Halpern <jmh@joelhalpern.com>
Terry Manderson <terry.manderson@icann.org> Terry Manderson <terry.manderson@icann.org>
Internet Area Directors: Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.com> Ralph Droms <rdroms.ietf@gmail.com>
Jari Arkko <jari.arkko@piuha.net> Jari Arkko <jari.arkko@piuha.net>
Internet Area Advisor: Internet Area Advisor:
skipping to change at line 46 skipping to change at line 46
The basic idea behind the separation is that the Internet architecture The basic idea behind the separation is that the Internet architecture
combines two functions, routing locators, (where you are attached to the combines two functions, routing locators, (where you are attached to the
network) and identifiers (who you are) in one number space: The IP network) and identifiers (who you are) in one number space: The IP
address. Proponents of the separation architecture postulate that address. Proponents of the separation architecture postulate that
splitting these functions apart will yield several advantages, including splitting these functions apart will yield several advantages, including
improved scalability for the routing system. The separation aims to improved scalability for the routing system. The separation aims to
decouple locators and identifiers, thus allowing for efficient decouple locators and identifiers, thus allowing for efficient
aggregation of the routing locator space and providing persistent aggregation of the routing locator space and providing persistent
identifiers in the identifier space. identifiers in the identifier space.
LISP requires no changes to end-systems or to most routers. LISP aims
for an incrementally deployable protocol.
A number of approaches are being looked at in parallel in other A number of approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs. published as IRTF-track Experimental RFCs.
The LISP WG is chartered to work on the LISP base protocol, completing The LISP WG has completed the first set of Experimental RFCs
describing the Locator/ID Separation Protocol. LISP requires no
changes to end-systems or to routers that do not directly participate
in the LISP deployment. LISP aims for an incrementally deployable
protocol.
The LISP WG is chartered to continue work on the LISP base protocol, completing
the ongoing work, and any items which directly impact LISP protocol the ongoing work, and any items which directly impact LISP protocol
structures and are related to using LISP for improving Internet routing structures and which are related to using LISP for improving Internet routing
scalability. Specifically, the group will work on: scalability. Specifically, the group will work on:
- LISP security threats and solutions - Architecture description: This document will describe the
- MIBs architecture of the entire LISP system, making it easier to read the
- deployment models rest of the LISP specifications and providing a basis for discussion
- allocation of EID space about the details of the LISP protocols.
- alternate mapping system designs
- Deployment models: This document will describe what kind of
deployments can be expected for LISP, and give operational advice on
how they can be set up.
- A description of the impacts of LISP: This document will describe
the problems that LISP is intended to address and the impacts that
employing LISP has. While the work on LISP was initiated by Internet
routing scaling concerns, there has also been an interest on
improved solutions to a number of different problems, such as
traffic engineering. This document should describe problem areas
(such as scaling or traffic engineer) where LISP is expected to have
a positive effect, as well as any tradeoffs that are caused by
LISP's design.
- LISP security threats and solutions: This document will describe the
security analysis of the LISP system, what issues it needs to
protect against, and a solution that helps defend against those
issues. The replay attack problem discussed on the mailing list
should be included in this work.
- Allocation of Endpoint IDentifier (EID) space: This document
requests address space to be used for the LISP experiment as
identifier space
- Alternate mapping system designs: Develop alternative mapping
designs to be tested.
- Data models for management of LISP.
The first three items need to be completed first before other items
can be submitted as RFCs. The three first documents also need to
complement each other, by describing how the architecture supports a
solution for a particular problem area and how the solution can be
deployed to help with that problem.
In addition, if work chartered in some other IETF WG requires changes In addition, if work chartered in some other IETF WG requires changes
in the LISP base protocol or any items which directly impact LISP in the LISP base protocol or any items which directly impact LISP
protocol structures, then the LISP WG is chartered to work on such protocol structures, then the LISP WG is chartered to work on such
changes. changes.
The working group will encourage and support interoperable LISP
implementations as well as defining requirements for alternate mapping
systems. The Working Group will also develop security profiles for LISP
and the various LISP mapping systems.
It is expected that the results of specifying, implementing, and testing It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF to LISP will be fed to the general efforts at the IETF and IRTF to
understand which type of a solution is optimal. The LISP WG is not understand which type of a solution is optimal. The LISP WG is not
chartered to develop a standard solution for solving the routing chartered to develop a standard solution for solving the routing
scalability problem at this time. The specifications developed by the WG scalability problem at this time. The specifications developed by the WG
are Experimental and labeled with accurate disclaimers about their are Experimental and labeled with accurate disclaimers about their
limitations and not fully understood implications for Internet traffic. limitations and not fully understood implications for Internet traffic.
In addition, as these issues are understood, the working group will In addition, as these issues are understood, the working group will
analyze and document the implications of LISP on Internet traffic, analyze and document the implications of LISP on Internet traffic,
applications, routers, and security. This analysis will explain what applications, routers, and security.
role LISP can play in scalable routing. The analysis should also look at
scalability and levels of state required for encapsulation,
decapsulation, liveness, and so on as well as the manageability and
operability of LISP. Specifically, the group will work on:
- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
experience
- describing the implications of employing LISP
- operational guidance for using LISP
Goals and Milestones Goals and Milestones
Jun 2012 Forward draft-ietf-lisp-mib to the IESG September 2012: Submit an architecture description to the IESG for
Jun 2012 Forward draft-ietf-lisp-sec to the IESG publication as an Experimental RFC
Jun 2012 Forward to the IESG an operational document which should
include cache management and ETR synchronization September 2012: Submit a deployment model document to the IESG for
techniques (draft-ietf-lisp-deployment). publication as an Experimental RFC
Oct 2012 Forward to the IESG a document providing a solution
to replay issues with Map-Register/Map-Notify September 2012: Submit a LISP impact discussion document to the IESG
for publication as an Experimental RFC
October 2012: Submit a LISP threats analysis document to the IESG for
publication as an Experimental RFC
October 2012: Submit an EID allocation document to the IESG for
publication as an Experimental RFC
January 2013: Submit an lternate mapping system designs to the IESG
for publication as an Experimental RFC
March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC
 End of changes. 8 change blocks. 
27 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--------------030501050705050305070607 Content-Type: text/plain; name="charter-new-proposal-from-the-iesg-ver2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="charter-new-proposal-from-the-iesg-ver2.txt" Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-02-14 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Goals and Milestones September 2012: Submit an architecture description to the IESG for publication as an Experimental RFC September 2012: Submit a deployment model document to the IESG for publication as an Experimental RFC September 2012: Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC October 2012: Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC October 2012: Submit an EID allocation document to the IESG for publication as an Experimental RFC January 2013: Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC March 2013: Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC --------------030501050705050305070607-- From wwwrun@ietfa.amsl.com Tue Feb 14 14:23:16 2012 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id CF29521E800E; Tue, 14 Feb 2012 14:23:16 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120214222316.CF29521E800E@ietfa.amsl.com> Date: Tue, 14 Feb 2012 14:23:16 -0800 (PST) Cc: lisp@ietf.org Subject: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:23:17 -0000 A modified charter has been submitted for the Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, March 1, 2011. Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-02-14 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Goals and Milestones September 2012: Submit an architecture description to the IESG for publication as an Experimental RFC September 2012: Submit a deployment model document to the IESG for publication as an Experimental RFC September 2012: Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC October 2012: Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC October 2012: Submit an EID allocation document to the IESG for publication as an Experimental RFC January 2013: Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC March 2013: Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC From dino@cisco.com Tue Feb 14 14:48:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B621E8105 for ; Tue, 14 Feb 2012 14:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.278 X-Spam-Level: X-Spam-Status: No, score=-8.278 tagged_above=-999 required=5 tests=[AWL=2.321, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6skdblo-0KD for ; Tue, 14 Feb 2012 14:48:44 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D39E321E80E1 for ; Tue, 14 Feb 2012 14:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1833; q=dns/txt; s=iport; t=1329259724; x=1330469324; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YQc4qzujfV8IHspJ/aZGmkJibwTL86xfnvSK0Z5sIWQ=; b=j2NdjzOR6YsMdz/Oh6FLXVtFjYXlXS3rTLfEeKlhc3n8FxbcYKEIUvvQ 5rpxatGighpOs2akaHfTbZFQL5iIticBb3yrfaJdnsz6BgHh79chIt6tj y7kHVUJL6/3FxrHvUkWjRowMEYR8XdD7glaXmE+cgLby97aGO+VcfHaxp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGnjOk+rRDoH/2dsb2JhbABDsFSBB4FyAQEBAwEBAQEPAVsLBQsLEjQnIg4GExoIh1oJmhcBnlYEi1cDCAQJDAUUBgYGCAMDCwEDBgMFDAERAwKEIhEHAwiCTGMEiEqDboh6kwU X-IronPort-AV: E=Sophos;i="4.73,419,1325462400"; d="scan'208";a="30235856" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Feb 2012 22:48:44 +0000 Received: from sjc-vpn6-590.cisco.com (sjc-vpn6-590.cisco.com [10.21.122.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1EMmivX021059; Tue, 14 Feb 2012 22:48:44 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: <4F3ADCB0.60800@piuha.net> Date: Tue, 14 Feb 2012 14:48:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3ADCB0.60800@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: lisp@ietf.org Subject: Re: [lisp] base specification, working group charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:48:45 -0000 > I have some news for you. The LISP base specification has just been = approved yesterday, joining the three other documents from this working = group that had already been approved earlier. We'll be working with the = remaining two in the coming weeks. I thought we have 3 more remaining. That is interworking, ms, and = map-versioning. Off by one error? What is waiting RFC editor queue is main, multicast, lig, alt.=20 So we are only 4 out of 7 complete. Please confirm Jari. Dino > The other piece of news is that the IESG has reviewed and discussed = your proposed charter, and had a number of suggested changes. The main = thrust of the changes is as follows: >=20 > 1) Cut down the number of items to stay focused; the IESG felt that = there was too much material in the proposed charter. >=20 > 2) Make some items priority 1 deliverables and add some items that are = important. The IESG felt that as it had reviewed the base = specifications, it now had a good view of what documentation there is on = LISP and is still missing. In particular, it was felt that an = architecture specification that paints some of the bigger picture would = be valuable. >=20 > Please find attached the proposed charter revision from the IESG along = with a diff file to the one that was circulated in the WG list some time = ago. >=20 > We plan to approve this charter in the near future, if you have any = objections please bring them up as soon as possible either on the WG = mailing list or to iesg@ietf.org >=20 > Jari >=20 >=20 > = = _____________________________= __________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Tue Feb 14 22:56:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326C521F8584 for ; Tue, 14 Feb 2012 22:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqPx7hCp6SR1 for ; Tue, 14 Feb 2012 22:56:32 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFF021F8581 for ; Tue, 14 Feb 2012 22:56:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D5A8B2D35A; Wed, 15 Feb 2012 08:56:30 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oy22J-iphkh; Wed, 15 Feb 2012 08:56:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 089982CC3C; Wed, 15 Feb 2012 08:56:30 +0200 (EET) Message-ID: <4F3B571D.50502@piuha.net> Date: Wed, 15 Feb 2012 08:56:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Dino Farinacci References: <4F3ADCB0.60800@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] base specification, working group charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:56:33 -0000 On 15.02.2012 00:48, Dino Farinacci wrote: >> I have some news for you. The LISP base specification has just been approved yesterday, joining the three other documents from this working group that had already been approved earlier. We'll be working with the remaining two in the coming weeks. > I thought we have 3 more remaining. That is interworking, ms, and map-versioning. Off by one error? Correct. (The difference to my count was because I only counted the ones that are already in IESG process and had some unresolved Discusses, interworking is still in IETF Last Call. But yes, we need to complete that one as well.) Jari > > What is waiting RFC editor queue is main, multicast, lig, alt. > > So we are only 4 out of 7 complete. Please confirm Jari. > > Dino > >> The other piece of news is that the IESG has reviewed and discussed your proposed charter, and had a number of suggested changes. The main thrust of the changes is as follows: >> >> 1) Cut down the number of items to stay focused; the IESG felt that there was too much material in the proposed charter. >> >> 2) Make some items priority 1 deliverables and add some items that are important. The IESG felt that as it had reviewed the base specifications, it now had a good view of what documentation there is on LISP and is still missing. In particular, it was felt that an architecture specification that paints some of the bigger picture would be valuable. >> >> Please find attached the proposed charter revision from the IESG along with a diff file to the one that was circulated in the WG list some time ago. >> >> We plan to approve this charter in the near future, if you have any objections please bring them up as soon as possible either on the WG mailing list or to iesg@ietf.org >> >> Jari >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Wed Feb 15 07:56:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864F921F8567 for ; Wed, 15 Feb 2012 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.329 X-Spam-Level: X-Spam-Status: No, score=-8.329 tagged_above=-999 required=5 tests=[AWL=2.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqqa-3XI43vy for ; Wed, 15 Feb 2012 07:56:35 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9349A21F855E for ; Wed, 15 Feb 2012 07:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2319; q=dns/txt; s=iport; t=1329321395; x=1330530995; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bFkz2BJOF0r92Yecs/nOoeIJccJhZk28qiI3YLz8Y5k=; b=Ij3IQJrkdrx+X1HiRW+AuFvWTdnl3jb54dt1bMp0P7GFOfKBWh6nWJqH j/LGfw5R1cVlLG6Nw2PY0/duWJgRJNQF64cyVoJiL6xS6sfVsnQDi23Yz XbmwX5Wu/4MmvyuvYetX/tfy6i7lqgBu80yW2WW0fPaEvIpfG5r/Mgrqr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFbVO0+rRDoH/2dsb2JhbABDsEyBB4FyAQEFEgFbCwULCxIGLkkOBi0Ih2abEAGeWgSLXgMIAgEDAgUDCQYEAQoICAYGCQMJAgEJAgMKAYZzYwSITYNviHqTCQ X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="28922009" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Feb 2012 15:45:56 +0000 Received: from sjc-vpn6-975.cisco.com (sjc-vpn6-975.cisco.com [10.21.123.207]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1FFjW8f007756; Wed, 15 Feb 2012 15:45:56 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: <4F3B571D.50502@piuha.net> Date: Wed, 15 Feb 2012 07:45:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3ADCB0.60800@piuha.net> <4F3B571D.50502@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: lisp@ietf.org Subject: Re: [lisp] base specification, working group charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:56:39 -0000 Ack. Thanks for clarification. Dino On Feb 14, 2012, at 10:56 PM, Jari Arkko wrote: > On 15.02.2012 00:48, Dino Farinacci wrote: >>> I have some news for you. The LISP base specification has just been = approved yesterday, joining the three other documents from this working = group that had already been approved earlier. We'll be working with the = remaining two in the coming weeks. >> I thought we have 3 more remaining. That is interworking, ms, and = map-versioning. Off by one error? >=20 > Correct. >=20 > (The difference to my count was because I only counted the ones that = are already in IESG process and had some unresolved Discusses, = interworking is still in IETF Last Call. But yes, we need to complete = that one as well.) >=20 > Jari >>=20 >> What is waiting RFC editor queue is main, multicast, lig, alt. >>=20 >> So we are only 4 out of 7 complete. Please confirm Jari. >>=20 >> Dino >>=20 >>> The other piece of news is that the IESG has reviewed and discussed = your proposed charter, and had a number of suggested changes. The main = thrust of the changes is as follows: >>>=20 >>> 1) Cut down the number of items to stay focused; the IESG felt that = there was too much material in the proposed charter. >>>=20 >>> 2) Make some items priority 1 deliverables and add some items that = are important. The IESG felt that as it had reviewed the base = specifications, it now had a good view of what documentation there is on = LISP and is still missing. In particular, it was felt that an = architecture specification that paints some of the bigger picture would = be valuable. >>>=20 >>> Please find attached the proposed charter revision from the IESG = along with a diff file to the one that was circulated in the WG list = some time ago. >>>=20 >>> We plan to approve this charter in the near future, if you have any = objections please bring them up as soon as possible either on the WG = mailing list or to iesg@ietf.org >>>=20 >>> Jari >>>=20 >>>=20 >>> = = _____________________________= __________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 From narten@us.ibm.com Wed Feb 15 13:32:02 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6283B21E809B for ; Wed, 15 Feb 2012 13:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.286 X-Spam-Level: X-Spam-Status: No, score=-109.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHbsJ1bVjT5n for ; Wed, 15 Feb 2012 13:32:01 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id B034121E8032 for ; Wed, 15 Feb 2012 13:32:01 -0800 (PST) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Feb 2012 14:32:01 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 15 Feb 2012 14:31:59 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 939E619D8053; Wed, 15 Feb 2012 14:31:53 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1FLVm6D064496; Wed, 15 Feb 2012 14:31:49 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1FLVlAS018181; Wed, 15 Feb 2012 14:31:48 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-205-222.mts.ibm.com [9.65.205.222]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1FLVkXP018012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 14:31:47 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q1FLVB9E028114; Wed, 15 Feb 2012 16:31:11 -0500 Message-Id: <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> To: iesg@ietf.org In-reply-to: <20120214222316.CF29521E800E@ietfa.amsl.com> References: <20120214222316.CF29521E800E@ietfa.amsl.com> Comments: In-reply-to IESG Secretary message dated "Tue, 14 Feb 2012 14:23:16 -0800." Date: Wed, 15 Feb 2012 16:31:11 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12021521-3270-0000-0000-0000040D58FB X-Mailman-Approved-At: Thu, 16 Feb 2012 08:06:33 -0800 Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:32:02 -0000 A WG Review message for this WG already went out a month ago. What has changed to necessitate another Last Call? Could the-powers-that-be please make it easier for those who might care to understand if there is something here that we should know and possibly comment about? A simple explanation, or a pointer to diffs, etc. would do the job nicely. Thomas From jgs@juniper.net Thu Feb 16 09:01:51 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0621F8885; Thu, 16 Feb 2012 09:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmrXM8mG3cbl; Thu, 16 Feb 2012 09:01:51 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C155221F887F; Thu, 16 Feb 2012 09:01:50 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTz02eoyZh6qiblZbHgzCnX8ZOOc5Ed1T@postini.com; Thu, 16 Feb 2012 09:01:51 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 16 Feb 2012 09:00:20 -0800 From: John Scudder To: Thomas Narten Date: Thu, 16 Feb 2012 09:00:19 -0800 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: AczszHc80IPY7GmzT5Wq7GMDQHAsNw== Message-ID: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> In-Reply-To: <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , "iesg@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:01:51 -0000 Hi Thomas, On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote: > A WG Review message for this WG already went out a month ago. >=20 > What has changed to necessitate another Last Call? >=20 > Could the-powers-that-be please make it easier for those who might > care to understand if there is something here that we should know and > possibly comment about? >=20 > A simple explanation, or a pointer to diffs, etc. would do the job > nicely. Good question! I did go back and diff the last couple of versions and thoug= h this isn't the exhaustive diff, these are the key changes that caught my = eye: This text was lost from the previous draft charter: This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Specifically, the group will work on: - documenting areas that need experimentation - summarizing the results of implementation, experiments, and deployment experience - describing the implications of employing LISP - operational guidance for using LISP And so were these Goals and Milestones: Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013 Publish an example cache management specification. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. I'm not sure why these were removed, and I would like to see them reinstate= d or at least have a discussion about their removal. Thanks, --John= From jgs@juniper.net Thu Feb 16 09:37:06 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E637D21F8812; Thu, 16 Feb 2012 09:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+Bdxf-NLx8I; Thu, 16 Feb 2012 09:36:59 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B920721F87E9; Thu, 16 Feb 2012 09:36:58 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0+hxZlPh7yRzv/SJMMwHBXXsnD1IQw@postini.com; Thu, 16 Feb 2012 09:36:59 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 09:35:15 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q1GHZE124205; Thu, 16 Feb 2012 09:35:14 -0800 (PST) (envelope-from jgs@juniper.net) References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <201202161710.q1GHAPk1016460@cichlid.raleigh.ibm.com> From: "John G. Scudder" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" In-Reply-To: <201202161710.q1GHAPk1016460@cichlid.raleigh.ibm.com> Message-ID: <94FA36DB-2FDA-4F3D-B406-E60EDC86AD64@juniper.net> Date: Thu, 16 Feb 2012 12:34:39 -0500 To: Thomas Narten MIME-Version: 1.0 (1.0) X-Mailer: iPhone Mail (9A405) X-EXCLAIMER-MD-CONFIG: f8e27f27-03b2-4c3e-9447-119194e72cb6 Cc: "lisp@ietf.org" , "iesg@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:37:06 -0000 Thanks, Thomas. In case it's not obvious, Jari's message isn't responsive to= the points I raised in my own message so I'll look forward to discussing th= ose.=20 --John On Feb 16, 2012, at 12:10 PM, Thomas Narten wrote: > Hi John. >=20 > Turns out Jari sent a message with an overview of the changes. But it > only went to the lisp mailing list, to which I'm not subscribed.=20 >=20 > See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html >=20 > That is the sort of explanation I was looking for. >=20 > But since re-chartering is an IETF-wide discussion, I think it would > be helpful that these sorts of things get mentioned in the "WG Review" > messages. That would be helpful to the broader community. >=20 > Thomas >=20 From jmh@joelhalpern.com Thu Feb 16 18:26:19 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EA821F863D; Thu, 16 Feb 2012 18:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcLRd7C92ur1; Thu, 16 Feb 2012 18:26:19 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07721F863B; Thu, 16 Feb 2012 18:26:19 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CE475CAD41; Thu, 16 Feb 2012 18:26:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DCBBC1C087F; Thu, 16 Feb 2012 18:26:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A23231C0152; Thu, 16 Feb 2012 18:26:16 -0800 (PST) Message-ID: <4F3DBAC7.1010805@joelhalpern.com> Date: Thu, 16 Feb 2012 21:26:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ietf@ietf.org" , "lisp@ietf.org" , "iesg@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:26:19 -0000 If I may separate issues for a moment, the absence of milestones is because Terry and I have to come up with a proposal for them which matche sthe revised goals. If you read the rest of the differences, you will see that the general question of what LISP is aimed at providing is indeed still there. The largest single difference is the addition of the architecture draft, which the IESG considers a gating item for any of the longer term work (such as the security solutions or the additional mapping system. Some of the apparent removal is because, as Jari stated, the IESG has requested that the working group focus on fewer deliverables. Yours, Joel On 2/16/2012 12:00 PM, John Scudder wrote: > Hi Thomas, > > On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote: > >> A WG Review message for this WG already went out a month ago. >> >> What has changed to necessitate another Last Call? >> >> Could the-powers-that-be please make it easier for those who might >> care to understand if there is something here that we should know and >> possibly comment about? >> >> A simple explanation, or a pointer to diffs, etc. would do the job >> nicely. > > Good question! I did go back and diff the last couple of versions and though this isn't the exhaustive diff, these are the key changes that caught my eye: > > This text was lost from the previous draft charter: > > This analysis will explain what > role LISP can play in scalable routing. The analysis should also look at > scalability and levels of state required for encapsulation, > decapsulation, liveness, and so on as well as the manageability and > operability of LISP. Specifically, the group will work on: > > - documenting areas that need experimentation > - summarizing the results of implementation, experiments, and deployment > experience > - describing the implications of employing LISP > - operational guidance for using LISP > > And so were these Goals and Milestones: > > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > > Dec 2013 Publish an example cache management specification. > > Jun 2014 Summarize results of specifying, implementing, and testing > LISP and forward to IESG and/or IRTF. > > Jun 2014 Analyze and document the implications of LISP deployments in > Internet topologies and forward to IESG for publication. > > I'm not sure why these were removed, and I would like to see them reinstated or at least have a discussion about their removal. > > Thanks, > > --John From jari.arkko@piuha.net Fri Feb 17 04:46:09 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C25B21F87BE; Fri, 17 Feb 2012 04:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukAt+P2hG1WV; Fri, 17 Feb 2012 04:46:08 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1C621F87B7; Fri, 17 Feb 2012 04:46:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 411022D35A; Fri, 17 Feb 2012 14:46:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2mzuIFzAsyw; Fri, 17 Feb 2012 14:46:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 910502CC3C; Fri, 17 Feb 2012 14:46:05 +0200 (EET) Message-ID: <4F3E4C0D.5060105@piuha.net> Date: Fri, 17 Feb 2012 14:46:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Thomas Narten References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> In-Reply-To: <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 12:46:09 -0000 On 15.02.2012 23:31, Thomas Narten wrote: > A WG Review message for this WG already went out a month ago. > > What has changed to necessitate another Last Call? > > Could the-powers-that-be please make it easier for those who might > care to understand if there is something here that we should know and > possibly comment about? > > A simple explanation, or a pointer to diffs, etc. would do the job > nicely. > I should have sent the e-mail to the ietf@ietf.org list as well. Looks like you found the e-mail from the WG mailing list later in the thread, so I am not repeating it here any more. Long story short, the IESG members had plenty of opinions about what the working group should be doing, given the recent experience of processing many documents from the working group. I do agree that it would be useful to post the same message to other places where the review went. Sorry, I missed it in this case (or, to be precise, I was too busy to craft a second message focused on the recharter part only before you took notice...) Jari From jari.arkko@piuha.net Fri Feb 17 04:58:05 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75321F8535; Fri, 17 Feb 2012 04:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a2ZY5cuzrW3; Fri, 17 Feb 2012 04:58:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 99F2121F8533; Fri, 17 Feb 2012 04:58:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E58622D35A; Fri, 17 Feb 2012 14:58:03 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLDYXSI4HD8n; Fri, 17 Feb 2012 14:58:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 249212CC3C; Fri, 17 Feb 2012 14:58:03 +0200 (EET) Message-ID: <4F3E4EDB.7070509@piuha.net> Date: Fri, 17 Feb 2012 14:58:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ietf@ietf.org" , "lisp@ietf.org" , "iesg@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 12:58:05 -0000 John, The IESG had no specific objection to these parts, but we made the charter in general shorter and reformulated some of the results. In particular, the idea was to put much of the material that you pointed to into the "LISP impacts" document. In general, the IESG felt that we had to go back a bit, and describe more of the big picture - the architecture, what problem we are addressing, what the results and downsides are - than the technical details. But it was not intended that topics like scalability and amount of state could be left out. I do agree that the description of the impacts document is short at the moment, is there something that you'd like to lift to put in the new charter? Jari On 16.02.2012 19:00, John Scudder wrote: > Hi Thomas, > > On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote: > >> A WG Review message for this WG already went out a month ago. >> >> What has changed to necessitate another Last Call? >> >> Could the-powers-that-be please make it easier for those who might >> care to understand if there is something here that we should know and >> possibly comment about? >> >> A simple explanation, or a pointer to diffs, etc. would do the job >> nicely. > Good question! I did go back and diff the last couple of versions and though this isn't the exhaustive diff, these are the key changes that caught my eye: > > This text was lost from the previous draft charter: > > This analysis will explain what > role LISP can play in scalable routing. The analysis should also look at > scalability and levels of state required for encapsulation, > decapsulation, liveness, and so on as well as the manageability and > operability of LISP. Specifically, the group will work on: > > - documenting areas that need experimentation > - summarizing the results of implementation, experiments, and deployment > experience > - describing the implications of employing LISP > - operational guidance for using LISP > > And so were these Goals and Milestones: > > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > > Dec 2013 Publish an example cache management specification. > > Jun 2014 Summarize results of specifying, implementing, and testing > LISP and forward to IESG and/or IRTF. > > Jun 2014 Analyze and document the implications of LISP deployments in > Internet topologies and forward to IESG for publication. > > I'm not sure why these were removed, and I would like to see them reinstated or at least have a discussion about their removal. > > Thanks, > > --John From narten@us.ibm.com Thu Feb 16 09:40:55 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5184D21F8653 for ; Thu, 16 Feb 2012 09:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.093 X-Spam-Level: X-Spam-Status: No, score=-110.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULGYJ93rQPq5 for ; Thu, 16 Feb 2012 09:40:51 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8669721F8867 for ; Thu, 16 Feb 2012 09:40:51 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 Feb 2012 10:30:25 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 16 Feb 2012 10:30:23 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 91AADC40002; Thu, 16 Feb 2012 10:30:22 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1GHPnbg132570; Thu, 16 Feb 2012 10:30:22 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1GHBEhV024115; Thu, 16 Feb 2012 10:11:14 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-146-173.mts.ibm.com [9.49.146.173]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1GHB34Q023066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 10:11:05 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q1GHAPk1016460; Thu, 16 Feb 2012 12:10:25 -0500 Message-Id: <201202161710.q1GHAPk1016460@cichlid.raleigh.ibm.com> To: John Scudder In-reply-to: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> Comments: In-reply-to John Scudder message dated "Thu, 16 Feb 2012 09:00:19 -0800." Date: Thu, 16 Feb 2012 12:10:24 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12021617-7408-0000-0000-000002B8334E X-Mailman-Approved-At: Fri, 17 Feb 2012 08:07:14 -0800 Cc: "lisp@ietf.org" , "iesg@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:40:55 -0000 Hi John. Turns out Jari sent a message with an overview of the changes. But it only went to the lisp mailing list, to which I'm not subscribed. See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html That is the sort of explanation I was looking for. But since re-chartering is an IETF-wide discussion, I think it would be helpful that these sorts of things get mentioned in the "WG Review" messages. That would be helpful to the broader community. Thomas From internet-drafts@ietf.org Fri Feb 17 09:06:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DFD21E80B8; Fri, 17 Feb 2012 09:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxGoq5Qu0ZhA; Fri, 17 Feb 2012 09:06:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1AB21E803C; Fri, 17 Feb 2012 09:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120217170616.4076.48657.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 09:06:16 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:06:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : Darrel Lewis David Meyer Dino Farinacci Vince Fuller Filename : draft-ietf-lisp-interworking-04.txt Pages : 24 Date : 2012-02-17 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) (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 Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-04.txt From darlewis@cisco.com Fri Feb 17 09:20:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85721F85CF for ; Fri, 17 Feb 2012 09:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.317 X-Spam-Level: X-Spam-Status: No, score=-7.317 tagged_above=-999 required=5 tests=[AWL=1.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np5tJ1-y7Sj5 for ; Fri, 17 Feb 2012 09:20:46 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5521F8593 for ; Fri, 17 Feb 2012 09:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=46659; q=dns/txt; s=iport; t=1329499246; x=1330708846; h=from:mime-version:subject:date:references:cc:to: message-id; bh=/92MkP8yOClup3h5iIzCN/Q/VxyQCjeEpBPU756Ht58=; b=fVKwybRvIibhPuOAPuRSzxAoFsh8w3jRiWUCDfsKgYfrEeYsFEo0fHN6 U2jyIKZlBB/7qJufsPs+Js1V+yWeYFEDw0r+J3fWxQxOGCgxvj4RWXYMz InBeP/YqfO+pRFm0UHAZ/X1Jr0t5bynEhzkX57iKUUJ5t26WY6s/cvo1v k=; X-Files: draft-ietf-interworking-03-to-04-diffs.html : 42361 X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="html'217?scan'217,208,217";a="29336469" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 17 Feb 2012 17:20:46 +0000 Received: from [10.154.208.44] ([10.154.208.44]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1HHKkRG011460; Fri, 17 Feb 2012 17:20:46 GMT From: Darrel Lewis Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/mixed; boundary="Apple-Mail=_E2FB212A-3B4D-4C34-BCDD-14BE2BC99C45" Date: Fri, 17 Feb 2012 09:20:46 -0800 References: <20120217170616.4076.48657.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: X-Mailer: Apple Mail (2.1257) Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-interworking-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:20:49 -0000 --Apple-Mail=_E2FB212A-3B4D-4C34-BCDD-14BE2BC99C45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This update was in response to minor editorial comments during the = GEN-ART review of draft-ietf-lisp-interworking-03.txt An HTML diff of the 03-04 changes is attached. Thanks, -Darrel --Apple-Mail=_E2FB212A-3B4D-4C34-BCDD-14BE2BC99C45 Content-Disposition: attachment; filename=draft-ietf-interworking-03-to-04-diffs.html Content-Type: text/html; x-unix-mode=0644; name="draft-ietf-interworking-03-to-04-diffs.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-interworking-03.txt draft-ietf-lisp-interworking-04.txt 
Network Working Group                                           D. Lewis
Internet-Draft                                                  D. Meyer
Intended status: Experimental                               D. Farinacci
Expires: August 12, 20, 2012                                       V. Fuller
                                                     Cisco Systems, Inc.
                                                       February 9, 17, 2012

                  Interworking LISP with IPv4 and IPv6
                  draft-ietf-lisp-interworking-03.txt
                  draft-ietf-lisp-interworking-04.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)
   (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 Proxy Egress
   Tunnel Router (PETR) 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 12, 20, 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 . . . . . . . . . . . . . . . . . . .  6
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Routable EIDs  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Impact on Routing Table  . . . . . . . . . . . . . . . . .  8
     4.2.  Requirement for using 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 EID announcements . . . . . . . . . . . . . . . . . . 10
     5.2.  Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 10
     5.3.  Scaling PITRs  . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Impact of the PITRs placement in the network . . . . . . . 12
     5.5.  Benefit to Networks Deploying PITRs  . . . . . . . . . . . 12
   6.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13
     6.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending
           to non-LISP Sites  . . . . . . . . . . . . . . . . . . . . 14
     6.3.  LISP Sites with Hosts using RFC 1918 Addresses
           Sending Packets to Other LISP Sites  . . . . . . . . . . . 14
     6.4.  LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15
   7.  Proxy Egress Tunnel Routers  . . . . . . . . . . . . . . . . . 16
     7.1.  Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16
   8.  Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs
       (PETRs)  . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 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 is
   that EID prefixes are normally not advertised into the Internet's
   Default Free Zone (DFZ).  Specifically, only RLOCs 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 LISP-capable and those that are not.

   The first mechanism uses a new network element, the LISP Proxy
   Ingress Tunnel Router (PITR) 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), 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 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

   - Section 6 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 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
   the impact of LISP-NAT on 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 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 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 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 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) 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 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 LISP site whose addresses are used as
      both globally routable IP addresses and LISP EIDs.

   LISP Non-Routable (LISP-NR) Site:  A LISP site whose addresses are
      EIDs only, these EIDs are not found in the legacy Internet routing
      table.

   LISP Proxy Ingress Tunnel Router (PITR):  PITRs are used to provide
      interconnectivity between sites which use LISP EIDs and those
      which do not.  They act as gateways between those parts of the
      Internet which are not using LISP (the legacy Internet) A given
      PITR advertises one or more highly aggregated EID prefixes into
      the public Internet and acts as the ITR for traffic received from
      the public Internet.  LISP Proxy Ingress Tunnel Routers are
      described in Section 5.

   LISP Network Address Translation (LISP-NAT):  Network Address
      Translation between EID space assigned to 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 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 to EID space without changing its existing routing
   policy.

4.2.  Requirement for using BGP

   Non-LISP sites today use BGP to, among other things, enable ingress
   traffic engineering.  Relaxing this requirement 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 Tunnel Router, an approach
       that provides ITR functionality to bridge LISP-capable and non-
       LISP-capable sites.

   2.  Section 6 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 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 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 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 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) allow for non-LISP sites to send
   packets to LISP-NR sites.  A PITR is a new network element that
   shares many characteristics with the LISP ITR.  PITRs allow non-LISP
   sites to send packets to LISP-NR sites without any changes to
   protocols or equipment at the non-LISP site.  PITRs have two primary
   functions:

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

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

5.1.  PITR EID announcements

   A key part of PITR functionality is to advertise routes for highly-
   aggregated EID prefixes into part of the global routing system.
   Aggressive aggregation is performed to minimize the number of new
   announced routes.  In addition, careful placement of PITRs can
   greatly reduce the advertised scope of these new routes.  To this
   end, PITRs 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.

5.2.  Packet Flow with PITRs

   What follows is an example of the path a packet would take when using
   a PITR.  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 any covering aggregate are present in the global routing system.
   In other words, without the Proxy-ITR announcing 192.0.2.0/24, 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 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 route to 192.0.2.0/24 and the next hop is the PITR.

   5.  The PITR 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
       RLOC.

   6.  The PITR 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 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.  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 to be
   relatively simple - it will only have to encapsulate LISP packets.

5.3.  Scaling PITRs

   PITRs 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 to prevent it from receiving more traffic than it can handle:

   1.  The PITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that PITR.  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 in order to
       share the traffic using IP Anycast.  The asymmetric nature of
       traffic flows through the Proxy ITR means that operationally,
       deploying a set PITRs would be very similar to existing Anycasted
       services like DNS caches.  Multiple 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 placement in the network

   There are several approaches that a network could take in placing
   PITRs.  Placing the PITR 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 CRIO Core Router-Integrated Overlay [CRIO],
   have suggested grouping PITRs 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

   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 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-
   LISP sites and LISP-NR sites by ensuring that the LISP-NR's site
   addresses are always routable.  LISP-NAT accomplishes this by
   translating a host's source address from an 'inner' (LISP-NR EID)
   value to an 'outer' (LISP-R) value and keeping this translation in a
   table that it can reference for subsequent packets.

   In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to
   talk 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 packets to return to the site.

   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 sites that use RFC 1918 private EIDs speaking 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 a site is announcing its
   prefix into both the LISP mapping system as well as the Internet DFZ.
   This is because the LISP-R source's address is routable, and return
   packets will be able to natively reach the site.

6.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
   hosts by translating the LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be a either a PI or PA
   address.

   An example of this translation follows.  For this example, a site has
   been assigned a LISP-NR EID of 220.1.1.0/24. 203.0.113.0/24.  In order to utilize
   LISP-NAT, the site has also been provided the PA EID of
   128.200.1.0/24, 192.0.2.0/24,
   and uses the first address (128.200.1.1) (192.0.2.1) as the site's RLOC.  The rest
   of this PA space (128.200.1.2 (192.0.2.2 to
   128.200.1.254) 192.0.2.254) is used as a translation
   pool for this site's hosts who need to 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
          ==============================================================
          220.1.1.0/24   128.200.1.0/24  128.200.1.1    128.200.1.2-254
          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 220.1.1.2 203.0.113.2 sends a packet (which, for the purposes of this
   example is destined for a non-LISP site) to its default route (the
   ITR).  The ITR receives the packet, and determines that the
   destination is not a LISP site.  How the ITR makes this determination
   is up to 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 220.1.1.2
   203.0.113.2 to 128.200.1.2, 192.0.2.2, which is the first available address in the
   LISP-R EID space available to it.  The ITR keeps this translation in
   a table in order to reverse this process when receiving packets
   destined to
   128.200.1.2. 192.0.2.2.

   Finally, when the ITR forwards this packet without encapsulating it,
   it uses the entry in its LISP-NAT table to translate the returning
   packets' destination IPs to the proper host.

6.2.  LISP Sites 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, the LISP-NAT implementation acts much like
   an existing IPv4 NAT device.  The ITR providing the NAT service must
   use LISP-R EIDs for its global address pool as well as providing all
   the standard NAT functions required today.

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

6.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 a LISP EID.  After
   translation, the communication between source and destination ITR and
   ETRs continues as described in [LISP].

   An example of this translation and encapsulation follows.  For this
   example, a host has been assigned a RFC 1918 address of 192.168.1.2.
   In order to utilize LISP-NAT, the site also has been provided the
   LISP-R EID prefix of 192.0.2.0/24, and 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 used as a translation pool for this site's hosts
   who need to send packets to both non-LISP and LISP hosts.

   The Host 192.168.1.2 sends a packet destined for a non-LISP site to
   its default route (the ITR).  The ITR receives the packet and
   determines that the destination is a LISP site.  How the ITR makes
   this determination is up 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 this packet (see [LISP] for details).
   The ITR uses the site's RLOC as the LISP outer header's source and
   the translation address 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 and
   then forward to the proper host.

6.4.  LISP-NAT and multiple EIDs

   With LISP-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 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
   general, but the specific issue described above is unique 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,
   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 LISP sites to send
   packets to non-LISP sites 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 a new network element that,
   conceptually, acts as an ETR for traffic destined to non-LISP sites.
   This also has 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) and these would be routed directly to the
   corespondent site's ETR.  All other packets (those destined to non-
   LISP sites) will be sent to the originating site's PETR.

   There are two primary reasons why sites would want to utilize a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks. (see section 9)

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where some of the intermediate network
      does not support the particular IP protocol desired (v4 or v6).
      PETRs can allow this LISP site's data to 'hop over' this by
      utilizing LISP's support 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 the aid of a
   Proxy-ETR (or PETR).  An ITR is simply configured to send all non-
   LISP traffic, which it normally would have forwarded natively (non-
   encapsulated), to a PETR.  In the case where the ITR uses a Map-
   Resolver(s), the ITR will encapsulate packets that match the received
   Negative Map-Cache to the configured Proxy-ETR(s).  In the case where
   the ITR is connected to the mapping system 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 use the LISP (outer) header's destination address to route the
   packets toward the configured Proxy-ETR.

   A PETR should verify the (inner) source EID of the packet at time of
   decapsulation in order to verify that this is from a configured LISP
   site.  This is to prevent spoofed inner sources from being
   encapsulated through the Proxy-ETR.

   What follows is an example of the path a packet would take when using
   a PETR.  In this example, the LISP-NR (or LISP-R) site is given the
   EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP
   site with the IP prefix of 198.51.100.0/24.  For the purposes of this
   example, the destination (198.51.100.0/24) is found in the Internet's
   routing system.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup for the destination, and gets
       198.51.100.100 (a Ip address of a host in the non-LISP site) in
       return.

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

   3.  The CE is a LISP ITR, and is configured to encapsulate traffic
       destined for non-LISP sites to a Proxy-ETR.

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

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

   Note that in this 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.

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

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

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) and Proxy-ETRs (PETRs) 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 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 to enable Interworking), packets will have the 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 traffic destined to 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
   [RFC2434].
   [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.

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

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

   [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
--Apple-Mail=_E2FB212A-3B4D-4C34-BCDD-14BE2BC99C45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-04.txt > Date: February 17, 2012 9:06:16 AM PST > To: i-d-announce@ietf.org > Cc: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : Interworking LISP with IPv4 and IPv6 > Author(s) : Darrel Lewis > David Meyer > Dino Farinacci > Vince Fuller > Filename : draft-ietf-lisp-interworking-04.txt > Pages : 24 > Date : 2012-02-17 >=20 > 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) > (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 Proxy Egress > Tunnel Router (PETR) to handle cases where a LISP ITR cannot send > packets to non-LISP sites without encapsulation. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-04.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_E2FB212A-3B4D-4C34-BCDD-14BE2BC99C45-- From jgs@juniper.net Mon Feb 20 12:07:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9621F87E6; Mon, 20 Feb 2012 12:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRKmGrXO5BLn; Mon, 20 Feb 2012 12:07:38 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id EF1D521F8793; Mon, 20 Feb 2012 12:07:37 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT0KoA/xbFsMl8sgdthOFtWqrttItV0Dx@postini.com; Mon, 20 Feb 2012 12:07:38 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 20 Feb 2012 12:07:00 -0800 From: John Scudder To: Jari Arkko Date: Mon, 20 Feb 2012 12:06:58 -0800 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: AczwCzRJw3iM7wjfRRmX7r5+mkCpdw== Message-ID: <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> In-Reply-To: <4F3E4EDB.7070509@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:07:39 -0000 Jari, I appreciate that brevity is desirable. I think in this case, the compressi= on process may have been unintentionally lossy. Let me say what in my view = was lost: 1. In discussions within the LISP WG it's frequently stated that experiment= ation will resolve some disputed question. Given this WG reliance on experi= mentation to resolve architectural issues, it seems desirable that such exp= erimentation be recognized as a first-class output of the group, on a par w= ith the architecture itself (something you have identified as a high priori= ty). As with any experiment, it's important to document the experiments tha= t were performed, and their outcomes. I do see that this is captured at a high level here: "It is expected that= the results of specifying, implementing, and testing LISP will be fed to t= he general efforts at the IETF and IRTF to understand which type of a solut= ion is optimal." However, there are no milestones to correspond with this e= xpectation. It generally seems sensible to have a milestone for each expect= ation. Below I propose adding one. 2. LISP relies on caching, but it has been difficult to carry on architectu= ral discussion and analysis of LISP because cache management is unspecified= . In such WG discussions, it's common for it to be asserted that the proble= m is solvable, but the solution is left 'as an exercise for the reader' or = similar. To enable this impasse to be resolved, it was agreed that an examp= le cache management specification would be produced. This would enable disc= ussion about something concrete without resorting to argument by emphatic a= ssertion. 3. ETR synchronization is an important component for correct functioning of= the overall LISP system but similar to caching, it has been difficult to h= ave a concrete discussion about it. Similar to the above, this is why the p= revious version of the charter had an milestone for documenting it. Broadly, these points have in common that they remind us that the LISP WG h= as a stated bias for working towards the concrete and the quantifiable. I t= hink that is the high-order bit of what has been lost. You ask for something to lift to put in the new charter. Here are some sugg= ested edits: Add: DATE TBD: Publish an example cache management specification. DATE TBD: Publish an example ETR synchronization specification. Since you mention prioritizing the architecture document, one other alterna= tive would be to explicitly call out the above two items as needing to be a= ddressed in that document. This might make sense insofar as these are both = needs that arose in the process of trying to work through the LISP architec= ture (i.e. they identify incompletely documented or worked-out areas of the= architecture). DATE TBD: Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. (The 'summarize' item does not seem to be what you're envisioning for the '= impact' work item, but if that's incorrect I would be OK with making that w= ork item more explicit by adding the above text or similar.) Thanks, --John On Feb 17, 2012, at 7:58 AM, Jari Arkko wrote: John, The IESG had no specific objection to these parts, but we made the charter = in general shorter and reformulated some of the results. In particular, the= idea was to put much of the material that you pointed to into the "LISP im= pacts" document. In general, the IESG felt that we had to go back a bit, an= d describe more of the big picture - the architecture, what problem we are = addressing, what the results and downsides are - than the technical details= . But it was not intended that topics like scalability and amount of state = could be left out. I do agree that the description of the impacts document is short at the mom= ent, is there something that you'd like to lift to put in the new charter? Jari On 16.02.2012 19:00, John Scudder wrote: Hi Thomas, On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote: A WG Review message for this WG already went out a month ago. What has changed to necessitate another Last Call? Could the-powers-that-be please make it easier for those who might care to understand if there is something here that we should know and possibly comment about? A simple explanation, or a pointer to diffs, etc. would do the job nicely. Good question! I did go back and diff the last couple of versions and thoug= h this isn't the exhaustive diff, these are the key changes that caught my = eye: This text was lost from the previous draft charter: This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Specifically, the group will work on: - documenting areas that need experimentation - summarizing the results of implementation, experiments, and deployment experience - describing the implications of employing LISP - operational guidance for using LISP And so were these Goals and Milestones: Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013 Publish an example cache management specification. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. I'm not sure why these were removed, and I would like to see them reinstate= d or at least have a discussion about their removal. Thanks, --John From lear@cisco.com Wed Feb 22 22:38:47 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758911E8083; Wed, 22 Feb 2012 22:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRPUjlUXFjCz; Wed, 22 Feb 2012 22:38:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2346211E807F; Wed, 22 Feb 2012 22:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=130; q=dns/txt; s=iport; t=1329979126; x=1331188726; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ijq5NE2Rcuw/4vJJnVbK427ue9khtO+nJVlhci9yec0=; b=BQ54CMDWCaoN4wDieX2+/Kxsrd7/Ee/8olVICNDd3UtWH6aJvgfP3NdP el5nN7as1skG3tPT1ANGyKR5txNXbGQlWCJ+5EsgSZsoGki4H16eoBoHi XxzOlp+fQEkP3LSjsr09Wk7LOghmSrrtaySWqeHUNDYJld+u5JvL3w25N 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUjAGbeRU+Q/khN/2dsb2JhbABEhTSsHQEDAYEGgQeBcwEBAQQSARBWEAsOCgICBSECAg8CRgYNAQcBAR6nXgGMZYoegS+MAgECCwQFCgMDBwMCBQoIAQsBAQEBAgECAoNGgQJPCoMFgRYElTiSbg X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="130314992" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2012 06:38:45 +0000 Received: from dhcp-10-55-89-149.cisco.com (dhcp-10-55-89-149.cisco.com [10.55.89.149]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1N6cigx009726; Thu, 23 Feb 2012 06:38:44 GMT Message-ID: <4F45DEF4.202@cisco.com> Date: Thu, 23 Feb 2012 07:38:44 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> In-Reply-To: <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 06:38:47 -0000 On 2/20/12 9:06 PM, John Scudder wrote: > Jari, > > > 2. LISP relies on caching, LISP-ALT relies on caching. Eliot From hannu.flinck@nsn.com Thu Feb 23 02:01:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98421F8577 for ; Thu, 23 Feb 2012 02:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgrBCCbvWX5p for ; Thu, 23 Feb 2012 02:01:43 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id ADCAC21F8624 for ; Thu, 23 Feb 2012 02:01:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1NA1WFB020353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2012 11:01:32 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1NA1Q3r023861; Thu, 23 Feb 2012 11:01:29 +0100 Received: from FIESEXC008.nsn-intra.net ([10.159.0.16]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 11:01:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 12:01:28 +0200 Message-ID: In-Reply-To: <4F45DEF4.202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Aczx9dVMoPHmjquPToC9vX/yJquB1QAG844g References: <20120214222316.CF29521E800E@ietfa.amsl.com><201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com><4F3E4EDB.7070509@piuha.net><0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F45DEF4.202@cisco.com> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "ext Eliot Lear" , "John Scudder" X-OriginalArrivalTime: 23 Feb 2012 10:01:29.0651 (UTC) FILETIME=[1CFBF830:01CCF212] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 783 X-purgate-ID: 151667::1329991292-000015E0-1E55E41F/0-0/0-0 Cc: lisp@ietf.org Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:01:44 -0000 Just for the sake of clarity both Lisp and lisp-alt relies on caching. In Lisp there is EID-to-RLOC Cache in an ITR and ETR MAY create a cache entry that maps the source EID. =20 - Hannu -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of ext Eliot Lear Sent: Thursday, February 23, 2012 8:39 AM To: John Scudder Cc: iesg@ietf.org IESG; ietf@ietf.org list; lisp@ietf.org Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) On 2/20/12 9:06 PM, John Scudder wrote: > Jari, > > > 2. LISP relies on caching, LISP-ALT relies on caching. Eliot _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Thu Feb 23 02:15:13 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFAC21F8557; Thu, 23 Feb 2012 02:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A9QHaeLQKvs; Thu, 23 Feb 2012 02:15:12 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B88C721F84DA; Thu, 23 Feb 2012 02:15:10 -0800 (PST) Received: by wibhm9 with SMTP id hm9so776225wib.31 for ; Thu, 23 Feb 2012 02:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c2vtgB2GuN1ckRr+VxmIUD6LoyHlg/yQbEuypt3cirY=; b=qFG/sRMoGpgLIWVkHrgkWyCCzxIDXjp7V+jQiL8jYFWU6IMTxQpjTEgLPe0/ae6/nS y3kHMPbrliJl50sF3VGaUN6mVsWHJkmtQADWqZlxKyfbNOHTwoQcVJiyUXk8j3vHWPiS 3NNNaNvJ5QO+Q6F/HOfHico9rOByJWY37JP+4= Received: by 10.180.101.165 with SMTP id fh5mr1425449wib.10.1329992109961; Thu, 23 Feb 2012 02:15:09 -0800 (PST) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPS id dr5sm4608899wib.0.2012.02.23.02.15.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 02:15:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4F45DEF4.202@cisco.com> Date: Thu, 23 Feb 2012 11:15:07 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F45DEF4.202@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" , "iesg@ietf.org IESG" , "ietf@ietf.org list" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:15:13 -0000 Hello Eliot, May I ask you why you say that LISP+ALT relies on caching? LISP+ALT is just a BGP based overlay, where is the caching there (is the BGP RIB that you consider as a cache?). Cheers, Damien Saucez On 23 Feb 2012, at 07:38, Eliot Lear wrote: > > > On 2/20/12 9:06 PM, John Scudder wrote: >> Jari, >> >> >> 2. LISP relies on caching, > > LISP-ALT relies on caching. > > Eliot > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lear@cisco.com Thu Feb 23 04:48:00 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ED921F8763; Thu, 23 Feb 2012 04:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.24 X-Spam-Level: X-Spam-Status: No, score=-110.24 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWdVT9PAv6uq; Thu, 23 Feb 2012 04:48:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 79A5521F8752; Thu, 23 Feb 2012 04:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1810; q=dns/txt; s=iport; t=1330001279; x=1331210879; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bEXBy+n8xN8TlOUT4qnF/UwhJctyGFF+pg9i87vGmuc=; b=LItNHu2yKkQFVGEHwURHilVd4P5yr9iTXU5wdbzuWKpSWd0EKiC1xUlo dvtcNYv+sB2jmvjm1cPTXpvRv9FYOPW5GSPz5Woq3NkUdCuQ72wzUyCdt iNbKnXpIWTQr+5pYVIlfZnoyVNoHNEXFSFtrAimFvePbdFpXOnQamTJOK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACQ1Rk+Q/khL/2dsb2JhbABEhTStKYEHgWoFBAEBAQQSARBVARALAwEUCRYLAgIJAwIBAgFFBg0BBwEBHoUmgi6gFgGMZYoyjXADCAEMBQMChRAHCoMFgRYElTiSbg X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208,217";a="130356471" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2012 12:47:58 +0000 Received: from dhcp-10-55-89-149.cisco.com (dhcp-10-55-89-149.cisco.com [10.55.89.149]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1NClwNu013471; Thu, 23 Feb 2012 12:47:58 GMT Message-ID: <4F46357D.3050300@cisco.com> Date: Thu, 23 Feb 2012 13:47:57 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Damien Saucez References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F45DEF4.202@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/alternative; boundary="------------010405080704050603080501" Cc: "lisp@ietf.org" , "iesg@ietf.org IESG" , "ietf@ietf.org list" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:48:00 -0000 This is a multi-part message in MIME format. --------------010405080704050603080501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Damian, others, On 2/23/12 11:15 AM, Damien Saucez wrote: > Hello Eliot, > > May I ask you why you say that LISP+ALT relies on caching? > > LISP+ALT is just a BGP based overlay, where is the caching > there (is the BGP RIB that you consider as a cache?). An investigation I ran looked at the possibility of doing a "push" versus "pull" of the mappings. It's not where the main LISP group went, but it is possible. To be fair there is still caching of state, but the performance profile. See draft-lear-lisp-nerd. Eliot --------------010405080704050603080501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Damian, others,

On 2/23/12 11:15 AM, Damien Saucez wrote: 
Hello Eliot,

May I ask you why you say that LISP+ALT relies on caching?

LISP+ALT is just a BGP based overlay, where is the caching
there (is the BGP RIB that you consider as a cache?).

An investigation I ran looked at the possibility of doing a "push" versus "pull" of the mappings.  It's not where the main LISP group went, but it is possible.  To be fair there is still caching of state, but the performance profile.  See draft-lear-lisp-nerd.

Eliot
--------------010405080704050603080501-- From damien.saucez@gmail.com Thu Feb 23 04:57:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7B21F87BD for ; Thu, 23 Feb 2012 04:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp0vIxvJEuer for ; Thu, 23 Feb 2012 04:57:43 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD62921F87BC for ; Thu, 23 Feb 2012 04:57:42 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so737889wgb.13 for ; Thu, 23 Feb 2012 04:57:42 -0800 (PST) Received-SPF: pass (google.com: domain of damien.saucez@gmail.com designates 10.181.13.113 as permitted sender) client-ip=10.181.13.113; Authentication-Results: mr.google.com; spf=pass (google.com: domain of damien.saucez@gmail.com designates 10.181.13.113 as permitted sender) smtp.mail=damien.saucez@gmail.com; dkim=pass header.i=damien.saucez@gmail.com Received: from mr.google.com ([10.181.13.113]) by 10.181.13.113 with SMTP id ex17mr3125202wid.15.1330001862083 (num_hops = 1); Thu, 23 Feb 2012 04:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E0kbRtudxBVMfQTb8ArLbzqHkg0Lt+Bahp1UeuBLcD0=; b=csLJc0KV+6MTzhZ4hJZwQzyD2xx63lzz13NbjJJqAj4sP9DUwAla1wvQAAhBoN1rMd 5Uj0h4Hsj26sOmozDB4zMR3dAOFeuZFXBbAKWbOV40JtXx83Ai4q5h+4S2Ir7jGzeFip LKP8tapJA2Xsq0/yk0m3EZAJosdaymE1cnH5M= Received: by 10.181.13.113 with SMTP id ex17mr2555302wid.15.1330001861971; Thu, 23 Feb 2012 04:57:41 -0800 (PST) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPS id er8sm6378627wib.1.2012.02.23.04.57.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 04:57:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4F46357D.3050300@cisco.com> Date: Thu, 23 Feb 2012 13:57:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F45DEF4.202@cisco.com> <4F46357D.3050300@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1257) Cc: LISP mailing list list Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:57:43 -0000 Eliot, On 23 Feb 2012, at 13:47, Eliot Lear wrote: > Damian, others, >=20 > On 2/23/12 11:15 AM, Damien Saucez wrote: >> Hello Eliot, >>=20 >> May I ask you why you say that LISP+ALT relies on caching? >>=20 >> LISP+ALT is just a BGP based overlay, where is the caching >> there (is the BGP RIB that you consider as a cache?). >>=20 >=20 > An investigation I ran looked at the possibility of doing a "push" = versus "pull" of the mappings. It's not where the main LISP group went, = but it is possible. To be fair there is still caching of state, but the = performance profile. See draft-lear-lisp-nerd. I remember NERD very well and I think that NERD could be useful in some local environments. However, in the global Internet, NERD implies that every ITR has all the mappings and their associated churn which might impact the scalability. All that is nice but it does not answer my question, why do you say that = ALT relies on caching? And what do you mean by "to be fair there is still caching of = state"? Thank you, Damien Saucez >=20 > Eliot From lear@cisco.com Thu Feb 23 05:37:26 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF821F881D for ; Thu, 23 Feb 2012 05:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9NxjwFEylBT for ; Thu, 23 Feb 2012 05:37:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA9A321F881C for ; Thu, 23 Feb 2012 05:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=799; q=dns/txt; s=iport; t=1330004244; x=1331213844; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=784HT1tUs3mK5tiHW7xgDPv1S/nWu0RJG+NtJWAVn14=; b=CF4ZH53YINZy0qWa/JffpPK2j9NU9u/duRcC+t3h5a/ZCYZvDVEfTrq1 jr7xjshr977JZAfCoF85VmUSe1XsImvJcnOPALS8/TjxhwlOIzb/xtYYI ljZMzVt6ECrD83uGq89w32c2ghXvyMVLBDcK8bMnVWDUGNmuM04+XKTHT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM5ARk+Q/khN/2dsb2JhbABEhTStKYEHgXMBAQEDARIBEFUBBQsLGAICBRYLAgIJAwIBAgFFBg0BBwEBHodfoBIBjGWKMIEvi38DAQILBAUKAwMHAwIFCggBDAIDAwKFFwqDBYEWBJU4km4 X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="130362318" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2012 13:37:21 +0000 Received: from dhcp-10-55-89-149.cisco.com (dhcp-10-55-89-149.cisco.com [10.55.89.149]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1NDbJQq003381; Thu, 23 Feb 2012 13:37:20 GMT Message-ID: <4F46410D.2020901@cisco.com> Date: Thu, 23 Feb 2012 14:37:17 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Damien Saucez References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F45DEF4.202@cisco.com> <4F46357D.3050300@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:37:26 -0000 Damian, On 2/23/12 1:57 PM, Damien Saucez wrote: > Eliot, > > I remember NERD very well and I think that NERD could be useful in > some local environments. However, in the global Internet, NERD implies > that every ITR has all the mappings and their associated churn which > might impact the scalability. That's right. It might. > > All that is nice but it does not answer my question, why do you say that ALT relies on > caching? Pull implies caching. That is- you pull the routes you need. The BGP provides the overlay to find the right ETR to transmit the cache information to the ITR. > And what do you mean by "to be fair there is still caching of state"? Because NERD assumes presence and use of reachibility bits. That information would be cached. Eliot From jmh@joelhalpern.com Thu Feb 23 16:08:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7119D21F88BB for ; Thu, 23 Feb 2012 16:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw6jeheoUhBv for ; Thu, 23 Feb 2012 16:08:35 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 049D421F88B7 for ; Thu, 23 Feb 2012 16:08:35 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F2F1FCD0D1 for ; Thu, 23 Feb 2012 16:08:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DA71D321D96 for ; Thu, 23 Feb 2012 16:08:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 96E40321D94 for ; Thu, 23 Feb 2012 16:08:34 -0800 (PST) Message-ID: <4F46D503.1070002@joelhalpern.com> Date: Thu, 23 Feb 2012 19:08:35 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "lisp@ietf.org" References: <20120223202105.5579.98976.idtracker@ietfa.amsl.com> In-Reply-To: <20120223202105.5579.98976.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223202105.5579.98976.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: lisp - Requested session has been scheduled for IETF 83 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:08:35 -0000 The preliminary agenda for the Paris meeting has been announced. We have been given a 1.5 hour slot on Tuesday afternoon from 3:20 pm til 5pm. The details as provided to the WG chairs are below. yours, Joel -------- Original Message -------- Subject: lisp - Requested session has been scheduled for IETF 83 Date: Thu, 23 Feb 2012 12:21:05 -0800 From: "IETF Secretariat" CC: lisp-ads@tools.ietf.org, lisp-chairs@tools.ietf.org, wlo@amsl.com Dear Terry Manderson, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lisp Session 1 (1.5 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: 252B --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Locator/ID Separation Protocol Area Name: Internet Area Session Requester: Wanda Lo Number of Sessions: 1 Length of Session(s): 1.5 hours Number of Attendees: 75 Conflicts to Avoid: First Priority: forces sidr karp rrg grow savi armd Second Priority: intarea rtgarea rtgwg Special Requests: --------------------------------------------------------- From internet-drafts@ietf.org Tue Feb 28 15:46:31 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8157521F8574; Tue, 28 Feb 2012 15:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMzmk5JTUoNG; Tue, 28 Feb 2012 15:46:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9DF21F8547; Tue, 28 Feb 2012 15:46:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120228234618.20365.71720.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 15:46:18 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:46:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : Darrel Lewis David Meyer Dino Farinacci Vince Fuller Filename : draft-ietf-lisp-interworking-05.txt Pages : 24 Date : 2012-02-28 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 (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 the Proxy Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-05.txt From darlewis@cisco.com Tue Feb 28 15:50:13 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B521E8078; Tue, 28 Feb 2012 15:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MANGLED_LIST=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_HTML_SINGLETS=1.666, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIG2LZJrHO0T; Tue, 28 Feb 2012 15:50:07 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8D21F85E3; Tue, 28 Feb 2012 15:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=135804; q=dns/txt; s=iport; t=1330473007; x=1331682607; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZeIHenphRjIOlBpDIVhewbz2+TwdUfDWDTu6SXSb+ds=; b=XRaqjwrxVoXIQGNr5j81DuJa4hHHC0k5Z2SDjgYhYFFALpFdxu0EKKMr 4FTP58K2ECgypmO1TXsbZ/dDGgLRHOU8qWTxaXTCeH2FwUHaw7D9vHjOp iXZV8mLsOCBH9AyGF0KLcnMH8b9TttOJA1+LFBKX9kJZ7eFbuT+cfFn6L M=; X-Files: rfcdiff-draft-lisp-interworking-04-to-05.html, draft-ietf-lisp-interworking-05.txt : 84612, 44536 X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="txt'?html'217?scan'217,208,217";a="33216963" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Feb 2012 23:50:07 +0000 Received: from sjc-vpn7-1263.cisco.com (sjc-vpn7-1263.cisco.com [10.21.148.239]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1SNo64t015886; Tue, 28 Feb 2012 23:50:06 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/mixed; boundary="Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB" From: Darrel Lewis In-Reply-To: <20120228234618.20365.71720.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 15:50:06 -0800 Message-Id: <301ADB1E-B5A5-4249-A21E-20A6C68D2487@cisco.com> References: <20120228234618.20365.71720.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1257) Cc: lisp@ietf.org, i-d-announce@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-interworking-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:50:14 -0000 --Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, The -05 version updates the draft based on the detailed review of Rolf = Winter on behalf of the TSV Area. The major differences to the document are the re-ordering of the Terms = section to earlier in the document, and the movement of the Proxy-ETR = section to be near the Proxy-ITR section. Also Rolf spent a lot of time = finding nits and suggesting the proper, consistent use of terms within = the document - hopefully these have all been addressed. -05 and HTML diffs from 04 to -05 are attached. Thanks, -Darrel, on behalf of the draft-ietf-lisp-interworking authors. --Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB Content-Disposition: attachment; filename=rfcdiff-draft-lisp-interworking-04-to-05.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-draft-lisp-interworking-04-to-05.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-interworking-04.txt draft-ietf-lisp-interworking-05.txt 
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
--Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB Content-Disposition: attachment; filename=draft-ietf-lisp-interworking-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-interworking-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Lewis Internet-Draft D. Meyer Intended status: Experimental D. Farinacci Expires: September 1, 2012 V. Fuller Cisco Systems, Inc. February 29, 2012 Interworking LISP with IPv4 and IPv6 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 (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 the Proxy Egress Tunnel Router (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." Lewis, et al. Expires September 1, 2012 [Page 1] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 This Internet-Draft will expire on 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. Lewis, et al. Expires September 1, 2012 [Page 2] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 4.2. Requirement for 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. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10 5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11 5.4. Impact of the Proxy-ITRs placement in the network . . . . 12 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 13 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 16 7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets to Other LISP Sites . . . . . . . . . . . 16 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs (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 Lewis, et al. Expires September 1, 2012 [Page 3] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 1. Introduction This document describes interoperation mechanisms between LISP [LISP] sites which use non-globally-routed EIDs, and non-LISP sites. A key behavior of the separation of Locators and 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 (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 (Proxy-ETR), which act as an intermediate Egress Tunnel Router (ETR) for LISP sites which need to encapsulate 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 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 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 8 describes the relationship between asymmetric and 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 Lewis, et al. Expires September 1, 2012 [Page 4] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 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 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. Lewis, et al. Expires September 1, 2012 [Page 5] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 2. Definition of Terms Default Free Zone: The Default-Free Zone (DFZ) refers 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 LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only, these EIDs are not found in the legacy Internet 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 gateways between those parts of the Internet which are not using LISP (the legacy Internet) A given Proxy-ITR advertises one or more highly aggregated EID prefixes into the public Internet and acts as the ITR for traffic received from the public Internet. LISP Proxy-ITRs are described in Section 5. LISP Network Address Translation (LISP-NAT): Network Address Translation between EID space assigned to a site 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 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]. Lewis, et al. Expires September 1, 2012 [Page 6] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 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 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 (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. Lewis, et al. Expires September 1, 2012 [Page 7] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 addresses. 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 to EID space without changing its existing routing policy. 4.2. Requirement for sites to use BGP 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 sites. 2. Section 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 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 Lewis, et al. Expires September 1, 2012 [Page 8] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 therefore not recommended. That being said, single-homed sites (or multi-homed sites that are not leaking more specific exceptions) 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 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. Lewis, et al. Expires September 1, 2012 [Page 9] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 5. Proxy Ingress Tunnel Routers Proxy Ingress Tunnel Routers (Proxy-ITRs) allow for non-LISP sites to send packets to LISP-NR sites. A Proxy-ITR is a new network element that shares many characteristics with the LISP ITR. 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. Proxy-ITRs have two primary functions: Originating EID Advertisements: Proxy-ITRs advertise highly aggregated EID-prefix space on behalf of LISP sites so that non- LISP sites can reach them. Encapsulating Legacy Internet Traffic: Proxy-ITRs also encapsulate non-LISP Internet traffic into LISP packets and route them towards their destination RLOCs. 5.1. Proxy-ITR EID announcements A key part of Proxy-ITR functionality is to advertise routes for highly- aggregated EID prefixes into parts of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of Proxy- ITRs can greatly reduce the advertised scope of these new routes. To this end, 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 Proxy-ITRs. 5.2. Packet Flow with Proxy-ITRs What follows is an example of the path a packet would take when using a 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 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 Edge (CE) router and forwards the packet to the CE. Lewis, et al. Expires September 1, 2012 [Page 10] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 Proxy- ITR. 5. The 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 Proxy- ITR's RLOC. 6. The 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 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 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 Proxy-ITR to be relatively simple - it will only have to encapsulate LISP packets. 5.3. Scaling 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 Proxy-ITR to prevent it from receiving more traffic than it can handle: Lewis, et al. Expires September 1, 2012 [Page 11] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 1. The Proxy-ITR's aggregate routes might be selectively announced, giving a coarse way to control the quantity of traffic attracted by that 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 Proxy-ITRs in order to share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy-ITR means that operationally, deploying a set of Proxy-ITRs would be very similar to existing Anycasted services like DNS caches. Multiple 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 Proxy-ITRs placement in the network There are several approaches that a network could take in placing Proxy-ITRs. Placing the 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 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 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 Proxy-ITRs may attract more traffic, and therefore more revenue, from their customers. Lewis, et al. Expires September 1, 2012 [Page 12] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 6. Proxy Egress Tunnel Routers Proxy Egress Tunnel Routers (Proxy-ETRs) allow for LISP sites to send packets to non-LISP sites in the case where the access network does not allow the LISP site to send packets with the source address of the site's EID(s). A Proxy-ETR is a new network element that, conceptually, acts as an ETR for traffic destined to non-LISP sites. This also has 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) and these would be routed directly to the corespondent site's ETR. All other packets (those destined to non- LISP sites) will be sent to the originating site's Proxy-ETR. There are two primary reasons why sites would want to utilize a Proxy-ETR: Avoiding strict uRPF failures: Some provider's access networks require the source of the packets emitted to be within the addressing scope of the access networks. (see section 9) Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where some of the intermediate network does not support the particular IP protocol desired (v4 or v6). Proxy-ETRs can allow this LISP site's data to 'hop over' this by utilizing LISP's support for mixed protocol encapsulation. 6.1. Packet Flow with Proxy Egress Tunnel Routers Packets from a LISP site can reach a non-LISP site with the aid of a Proxy-ETR (or Proxy-ETR). An ITR is simply configured to send all non-LISP traffic, which it normally would have forwarded natively (non-encapsulated), to a Proxy-ETR. In the case where the ITR uses a Map- Resolver(s), the ITR will encapsulate packets that match the received Negative Map-Cache to the configured Proxy-ETR(s). In the case where the ITR is connected to the mapping system 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 use the LISP (outer) header's destination address to route the packets toward the configured Proxy-ETR. A Proxy-ETR should verify the (inner) source EID of the packet at time of decapsulation in order to verify that this is from a configured LISP site. This is to prevent spoofed inner sources from being encapsulated through the Proxy-ETR. What follows is an example of the path a packet would take when using Lewis, et al. Expires September 1, 2012 [Page 13] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 a Proxy-ETR. In this example, the LISP-NR (or LISP-R) site is given the EID prefix 192.0.2.0/24, and it is trying to reach host at a non- LISP site with the IP prefix of 198.51.100.0/24. For the purposes of this example, the destination (198.51.100.0/24) is found in the Internet's routing system. A full protocol exchange example follows: 1. The source host makes a DNS lookup for the destination, and gets 198.51.100.100 (an IP address of a host in the non-LISP site) in return. 2. The source host has a default route to Customer Edge (CE) router and forwards the packet towards the CE. 3. The CE is a LISP ITR, and is configured to encapsulate traffic destined for non-LISP sites to a Proxy-ETR. 4. The Proxy ETR decapsulates the LISP packet and forwards the original packet to its next hop. 5. The packet is then routed natively and directly to the destination (non-LISP) site 198.51.100.0/24. Note that in this 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. Lewis, et al. Expires September 1, 2012 [Page 14] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 7. 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- LISP sites and LISP-NR sites by ensuring that the LISP-NR's site addresses are always routable. LISP-NAT accomplishes this by translating a host's source address from an 'inner' (LISP-NR EID) value to an 'outer' (LISP-R) value and keeping this translation in a table that it can reference for subsequent packets. In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk 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 packets to return to the site. Note that this section is intended as rough overview of what could be done and not an exhaustive guide to IPv4 NAT. 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 sites that use RFC 1918 private EIDs speaking to other sites, who may be either LISP or non-LISP sites. Note that LISP-NAT is not needed in the case of LISP-R (routable global EIDs) sources. This case occurs when a site is announcing its prefix into both the LISP mapping system as well as the Internet DFZ. This is because the LISP-R source's address is routable, and return packets will be able to natively reach the site. 7.1. Using LISP-NAT with LISP-NR EIDs LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). This globally unique address may be a either a PI or PA address. An example of this translation follows. For this example, a site has been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24, and 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 used as a translation pool for this site's hosts who need to send packets to non-LISP hosts. Lewis, et al. Expires September 1, 2012 [Page 15] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 The translation table might look like the following: Site NR-EID Site R-EID Site's RLOC Translation Pool =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 example is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet, and determines that the destination is not a LISP site. How the ITR makes this determination is up to 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 192.0.2.2, which is the first available address in the LISP-R 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. Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the 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 hosts using RFC 1918 addresses desire to send packets to non-LISP hosts, the LISP-NAT implementation acts much like an existing IPv4 NAT device that is doing address only (not port translation. The ITR providing the NAT service must use LISP-R EIDs for its global address pool as well as providing all the standard NAT functions required today. The source of the packet must be translated to a LISP-R EID in 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 a LISP EID. After translation, the communication between source and destination ITR and ETRs continues as described in [LISP]. An example of this translation and encapsulation follows. For this Lewis, et al. Expires September 1, 2012 [Page 16] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 example, a host has been assigned a RFC 1918 address of 192.168.1.2. In order to utilize LISP-NAT, the site also has been provided the LISP-R EID prefix of 192.0.2.0/24, and 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 used as a translation pool for this site's hosts who need to send packets to both non-LISP and LISP hosts. The host 192.168.1.2 sends a packet destined for a non-LISP site to its default route (the ITR). The ITR receives the packet and determines that the destination is a LISP site. How the ITR makes this determination is up 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 this packet (see [LISP] for details). The ITR uses the site's RLOC as the LISP outer header's source and the translation address 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 and then forwards to the proper host. 7.4. LISP-NAT and multiple EIDs With LISP-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 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 general, but the specific issue described above is unique 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, using Proxy-ITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases. Lewis, et al. Expires September 1, 2012 [Page 17] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs (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 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 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 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 (Proxy-ITRs) and Proxy-ETRs (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. Lewis, et al. Expires September 1, 2012 [Page 18] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 9. Security Considerations Like any router or LISP ITR, 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 Proxy-ITRs to enable Interworking), packets will have the 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 egress traffic destined to non- LISP sites to the Proxy-ETR (thus ensuring the outer IP source address is the site's RLOC). Lewis, et al. Expires September 1, 2012 [Page 19] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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. Lewis, et al. Expires September 1, 2012 [Page 20] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 11. IANA Considerations This document creates no new requirements on IANA namespaces [RFC5226]. Lewis, et al. Expires September 1, 2012 [Page 21] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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, Lewis, et al. Expires September 1, 2012 [Page 22] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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. Lewis, et al. Expires September 1, 2012 [Page 23] =0C Internet-Draft Interworking LISP with IPv4 and IPv6 February 2012 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 Lewis, et al. Expires September 1, 2012 [Page 24] =0C --Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 28, 2012, at 3:46 PM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : Interworking LISP with IPv4 and IPv6 > Author(s) : Darrel Lewis > David Meyer > Dino Farinacci > Vince Fuller > Filename : draft-ietf-lisp-interworking-05.txt > Pages : 24 > Date : 2012-02-28 >=20 > 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 (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 the Proxy > Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR > cannot send packets to non-LISP sites without encapsulation. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-05.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_1823AEEC-EBFF-4F83-9B1E-2913445A93EB--