From gorry@erg.abdn.ac.uk Thu Jul 30 12:19:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23163A7222; Thu, 30 Jul 2009 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyurBZhdFd+K; Thu, 30 Jul 2009 12:19:34 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 36C043A71A6; Thu, 30 Jul 2009 12:18:50 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6UJIkxM026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 20:18:47 +0100 (BST) Message-ID: <4A71F215.2000604@erg.abdn.ac.uk> Date: Thu, 30 Jul 2009 21:18:45 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: ipv6@ietf.org, lisp@ietf.org References: <4A71EF25.7060307@erg.abdn.ac.uk> In-Reply-To: <4A71EF25.7060307@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: gorry@erg.abdn.ac.uk Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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, 30 Jul 2009 19:19:35 -0000 Thanks, As promised in 6man, I'll make a longer email on why I think setting the IPv6 UDP Checksum to zero is *not* the same as for IPv4 and what the implications are. We touched on this briefly in TSV today, but I'd like to take a little time to check the arguments - it seems there are many views here and it would be good to get to the bottom of this. A few other comments in-line, Gorry Gorry Fairhurst wrote: > On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote: > > >> >> This is a reminder that draft-fairhurst-6man-tsvwg-udptt and > >> >> > >> >> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 > >> >> > >> >> are still open and will be discussed at the 6man meeting Wednesday. > >> >> > >> >> Basically, one prescribes no checksum for the "outer" packet in > >> >> IPv6 encapsulations, the other a fixed checksum per flow. My > >> >> understanding is that this matter is relevant to LISP. > >> >> > >> >> If you are interested, please try to attend as a decision may be > >> >> made soon. > > > > > > Sorry, I have a conflict right now. But here is the position of one > > > LISP implementor and a coauthor of the LISP specifications: > > > > > > From a practical perspective, we prefer that a LISP encapsulator > > > (ITR and PTR) not incurred additional work when encapsulating > > > packets. The main LISP spec indicates: > > > > > > (1) The UDP checksum in the outer header MUST be set to 0 by an > > > encapsulator. > > > (2) The decapsulator MUST ignore the UDP checksum. > > > > > > We stand by this text and see no reason to change it. > > Are you using "we" to refer to yourself as both an implementor and a > co-author? ;-) > > FWIW, I have serious concerns about draft-fairhurst-6man-tsvwg-udptt, > as it involves overloading the UDP "next-header" value to refer to two > different header types (real UDP and UDP-TT). > One thing that was discussed in 6man was why thsi was different to UDP-Lite (which needed a separate protocol number), for the record there were two important differences here: 1) UDP-Lite implies very different semantics for the payload - i.e. error-tolerant data. Con fusing this with UDP data would not be good. 2) UDP-Lite needs to signal the link-driver that it is a UDP-Lite packet to atke advantage of the partial coverage feature. The header value currently provides this way. I do however, suggest we discuss this after discussing the UDP checksum issue. I'd be most happy to withdraw my draft if the decision is to preserve standard IPv6 UDP Checksum behaviour. > However, I also have serious concerns about using zero UDP checksums > with IPv6. > > > > > > There are no practical reasons to use outer header UDP checksums > > > regardless of the 4 combinations of packet types (v4-in-v4, v6-in- > > > v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers. > > I think that this statement is answering the wrong question... > > Since we have standards-track protocols that indicate that UDP > checksums must not be zero in IPv6 (for good reasons), I believe that > we should use valid UDP checksums in IPv6 outer headers, unless we can > provide practical (and compelling) reasons why _not_ to do so. So, > what are those reasons? > > If we do manage to achieve consensus that it makes sense to zero-out > the UDP checksum in IPv6 outer headers, there are a number of > questions we will have to answer... > > The problem with eliminating the UDP checksum in UDP over IPv6 is that > (unlike in IPv4) the IPv6 source and destination addresses are not > protected. So, the packet may be corrupted such that it is sent to > the wrong destination. When it arrives at the wrong destination, it > may be processed by an IP stack that is unaware of LISP. > Agreed. > We need to consider what will happen if one of these packets is > received by a non-LISP node. Are you assuming that non-LISP stacks > will simply throw away these packets, because they have zero (and > therefore invalid) UDP checksums? That's only a good assumption if we > assume that LISP is the _only_ protocol that will allow the use of > zero checksums. If the packet is processed by the stack, there > shouldn't be a non-LISP application on port 4342, so the packet should > be dropped. We should define, however, how the sending LISP node will > deal with an ICMPv6 "port unreachable" error, so that an error > received from the wrong destination does not interfere with > communication with the right destination. > I suggest LISP is unlikely to be the only application to use this. AMT has already suggested a use in hosts. I suggest there will be others, especially once this is in the end-stack. > We also need to consider the possibility that a packet will be > received by a different LISP node than the one for which it was > intended, or that it will arrive at the correct LISP destination with > the wrong source address in the external header. What happens in > those cases? > > Margaret > I'd be keen to continue this later (sorry, but I will be disappearing from email for the next week after the IETF). best wishes, Gorry From albert.e.manfredi@boeing.com Thu Jul 30 15:13:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946DC3A6D2D; Thu, 30 Jul 2009 15:13:34 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTE6fiplxzA6; Thu, 30 Jul 2009 15:13:33 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 5CF863A6D12; Thu, 30 Jul 2009 15:13:33 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n6UMDY7S018751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jul 2009 15:13:34 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n6UMDX2J019742; Thu, 30 Jul 2009 17:13:33 -0500 (CDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n6UMDXXt019737; Thu, 30 Jul 2009 17:13:33 -0500 (CDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 18:13:33 -0400 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, 30 Jul 2009 18:13:32 -0400 Message-ID: In-Reply-To: <66F0C005-04F8-4F4F-9D79-28BF6229BDF1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] IPv6 UDP checksum issue Thread-Index: AcoRV6Dsb7EK/9/BT+WhWIUgpe8pQwACxl4g References: <66F0C005-04F8-4F4F-9D79-28BF6229BDF1@cisco.com> From: "Manfredi, Albert E" To: "Dino Farinacci" X-OriginalArrivalTime: 30 Jul 2009 22:13:33.0469 (UTC) FILETIME=[FA2534D0:01CA1162] X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jul 2009 22:13:34 -0000 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Thursday, July 30, 2009 4:30 PM > > We also need to consider the possibility that a packet will be =20 > > received by a different LISP node than the one for which it was =20 > > intended, or that it will arrive at the correct LISP destination =20 > > with the wrong source address in the external header. What=20 > happens =20 > > in those cases? >=20 > This doesn't happen since the outer IP header is checksum. In IPv6? Where is the header checkcum? If the UDP checksum is zero, what protects the IP SA and DA? Bert From remi@remlab.net Fri Jul 31 00:06:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387C528C151; Fri, 31 Jul 2009 00:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw8piASBe9nX; Fri, 31 Jul 2009 00:06:37 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 41CEA28C144; Fri, 31 Jul 2009 00:06:37 -0700 (PDT) Received: by yop.chewa.net (Postfix, from userid 33) id D059E62A; Fri, 31 Jul 2009 09:06:36 +0200 (CEST) To: Lars Eggert MIME-Version: 1.0 Date: Fri, 31 Jul 2009 09:06:36 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: References: Message-ID: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jul 2009 07:06:38 -0000 On Thu, 30 Jul 2009 21:25:29 +0200, Lars Eggert wrote: > On 2009-7-29, at 14:02, Dino Farinacci wrote: >> From a practical perspective, we prefer that a LISP encapsulator (ITR >> and PTR) not incurred additional work when encapsulating packets. > > could you share some data on how much of a performance impact we're > talking about here? I was under the (maybe naive) impression that > checksum offloading was practically ubiquitous these days. On high-end hardware, I guess it is indeed. >> The main LISP spec indicates: >> >> (1) The UDP checksum in the outer header MUST be set to 0 by an >> encapsulator. >> (2) The decapsulator MUST ignore the UDP checksum. >> >> We stand by this text and see no reason to change it. > > This is in direct conflict with what RFC2460 says, and I'd personally > would find it problematic to approve publication of an Experimental > protocol that did this, unless there was an IETF consensus on a > standards-track document that would update RFC2460 accordingly. Such a > document would IMO need to show extremely strong arguments for why > this change is needed. Updating RFC2460 is also in direct conflict > with the message that the IETF has been trying to send, namely, that > IPv6 is stable and done. Is this really worth it? Yep. Sounds like this would require a third datagram protocol number, that is basically UDP except the checksum would only covering the IPv6 and transport header. Hmmph, this is just like UDP-Lite really but it seems like there is opposition to overloading UDP-Lite. Then the 64-translators would convert it to normal UDP/IPv4... ? -- RĂ©mi Denis-Courmont From pekkas@netcore.fi Fri Jul 31 00:47:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0A83A6C27; Fri, 31 Jul 2009 00:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPpRRcMgzYgh; Fri, 31 Jul 2009 00:47:25 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 661843A6B21; Fri, 31 Jul 2009 00:47:24 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n6V7lJjg016922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 10:47:19 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n6V7lJUR016919; Fri, 31 Jul 2009 10:47:19 +0300 Date: Fri, 31 Jul 2009 10:47:19 +0300 (EEST) From: Pekka Savola To: byzek In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-885446919-1249026262=:16694" Content-ID: X-Virus-Scanned: clamav-milter 0.95.2 at otso.netcore.fi X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jul 2009 07:47:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-885446919-1249026262=:16694 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 30 Jul 2009, byzek wrote: > It's not about performance; a large percentage of the currently-deployed > hardware canąt do UDP checksum calculations during encapsulation because it > doesnąt have access to the entire packet. Most hardware is streamlined to > only provide the first n bytes of a packet to the forwarding engine, where > typically n < 128. I'm somewhat sympathetic to this concern, but I've been assured that it's possible to compute the outer checksum by doing an incremental checksum calculation (see e.g. RFC1624) using the inner packet's checksum. This would not require the access to the whole packet. This might work at least when encapsulating IPv4 over IPv6 UDP; I don't see how you could do this with IPv6 over IPv6 UDP due to the lack of "base" checksum. Any thoughts on how applicable this could be? >From the point of view of AMT specification, I don't see the need for IPv6 UDP encapsulation, even if you buy the LAG argument (I'm not sure if I can see 10G+ of traffic being LISP encapsulated between a couple of routers), it doesn't apply to AMT due to different traffic patterns. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-885446919-1249026262=:16694-- From fred@cisco.com Fri Jul 31 11:03:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26AC3A6825; Fri, 31 Jul 2009 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.181 X-Spam-Level: X-Spam-Status: No, score=-105.181 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FKoHEcBkgmw; Fri, 31 Jul 2009 11:03:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0869B3A6B36; Fri, 31 Jul 2009 11:03:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAIHOckqrR7MV/2dsb2JhbABGukuIKZBGBYQYgU8 X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208";a="357971565" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2009 18:03:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6VI3Uhg009782; Fri, 31 Jul 2009 11:03:30 -0700 Received: from [10.242.10.226] ([10.21.79.48]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6VI3TLe023925; Fri, 31 Jul 2009 18:03:29 GMT Message-Id: From: Fred Baker To: Lars Eggert In-Reply-To: <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 07:50:33 +0200 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1730; t=1249063410; x=1249927410; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=UTQCCEBYcmTBVX62BwXUH9GrakmtoGwMq4EL3hgPO4U=; b=UC2hT7ix5dH/6wbbwsgt2k3rG/1ixkMCE+kHb9/bCQ9GHYTxDOrAo35G1I 17xQe1rrWFOi29X/xkilO/K9OXAgGUlvjQk4q7vbXUdaDcqaYWmXhAn1B0Pq RkE3hnTrlugyTUqxW7CIQO3exOpfEV5pQuzjkw1nevY32bBW8e3Jo=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: "ipv6@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jul 2009 18:03:29 -0000 RIP is a router/router protocol and uses UDP... SNMP is used to manage routers and uses UDP... Yes, I wish UDP had never been invented so that people would write transports that actually did what they intended, but folks use UDP instead and build the transport in the application. On Jul 31, 2009, at 12:27 AM, Lars Eggert wrote: > Hi, > > On 2009-7-30, at 22:22, Noel Chiappa wrote: >>> From: Lars Eggert >> >>> This is in direct conflict with what RFC2460 says, and I'd >>> personally >>> would find it problematic to approve publication of an Experimental >>> protocol that did this, unless there was an IETF consensus on a >>> standards-track document that would update RFC2460 accordingly. >>> Such a >>> document would IMO need to show extremely strong arguments for why >>> this >>> change is needed. >> >> This is for an inter-router packet carriage use, not end-end. Why >> the dickens >> should there be a mandatory checksum on the data in the packet for >> sending a >> packet from one router to another? > > Since we're up-levelling the discussion, I don't understand why one > would use UDP as a router-router protocol in the first place, > especially for IPv6, where the chance that the packet will hit a NAT > are probably exactly zero. > > What I'm saying is that *if* UDP us used, it needs to be used > according to the RFCs that capture the IETF consensus on their use, > or the IETF consensus must be revised. > > Lars > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From benny+usenet@amorsen.dk Fri Jul 31 11:19:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB143A6E16; Fri, 31 Jul 2009 11:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4z1NSH+L-iF; Fri, 31 Jul 2009 11:19:34 -0700 (PDT) Received: from gate1.ipvision.dk (gate1.ipvision.dk [217.195.186.3]) by core3.amsl.com (Postfix) with ESMTP id A8D7C3A6DA1; Fri, 31 Jul 2009 11:18:42 -0700 (PDT) Received: from [10.1.27.9] (helo=ursa.amorsen.dk) by gate1.ipvision.dk with esmtp (Exim 4.69) (envelope-from ) id 1MWwgg-00015s-G2; Fri, 31 Jul 2009 20:18:41 +0200 Received: by ursa.amorsen.dk (Postfix, from userid 500) id 8F178104094; Fri, 31 Jul 2009 20:17:52 +0200 (CEST) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090731134740.CC8436BE5CC@mercury.lcs.mit.edu> From: Benny Amorsen Date: Fri, 31 Jul 2009 20:17:52 +0200 In-Reply-To: <20090731134740.CC8436BE5CC@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 31 Jul 2009 09\:47\:40 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jul 2009 18:19:35 -0000 jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > The UDP checksum in the outer header on LISP user-data does nothing, is > expensive/impossible to compute (depending on the hardware), and therefore the > correct practical engineering choice is to not compute it. You will probably eventually see PC-based routers which verify all checksums and drop invalid ones before letting the CPU see them, if the IPv6 specs allow it. PC NIC's are optimized for host use, not for routing, and therefore they look at the whole packets anyway. Most of them probably don't do much for IPv6 yet, but that is only a matter of time. Now such routers may forever be sufficiently rare on the open Internet that it is not a concern for LISP deployment. It seems prudent to try to get a formal exception from the usual UDP checksum rules if you really want to go for the no-checksum option. Personally I would drop zero checksum UDP packets with a rate-limited ICMP error when doing the LISP encapsulation. I would expect the number of zero-checksum UDP packets to drop as more NIC's get the checksum feature. /Benny From albert.e.manfredi@boeing.com Fri Jul 31 13:57:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15073A6A35; Fri, 31 Jul 2009 13:57:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-qviuQyzO10; Fri, 31 Jul 2009 13:57:09 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 54F103A6E27; Fri, 31 Jul 2009 13:57:09 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n6VKv8LL022219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 13:57:08 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n6VKv86x018333; Fri, 31 Jul 2009 13:57:08 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n6VKv6w6018272; Fri, 31 Jul 2009 13:57:08 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 16:57:07 -0400 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: Fri, 31 Jul 2009 16:57:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] IPv6 UDP checksum issue Thread-Index: AcoSCUA535FzUbHuQ2q23DwzAElvQgAGAwdg References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu><193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> From: "Manfredi, Albert E" To: "Fred Baker" X-OriginalArrivalTime: 31 Jul 2009 20:57:07.0584 (UTC) FILETIME=[77287000:01CA1221] X-Mailman-Approved-At: Sun, 02 Aug 2009 01:40:11 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jul 2009 20:57:10 -0000 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > RIP is a router/router protocol and uses UDP... > SNMP is used to manage routers and uses UDP... >=20 > Yes, I wish UDP had never been invented so that people would write =20 > transports that actually did what they intended, but folks use UDP =20 > instead and build the transport in the application. Or an alternative wish, an IPv6 option of header checksum? Bert From brian.e.carpenter@gmail.com Sun Aug 2 15:16:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954843A6852; Sun, 2 Aug 2009 15:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuOfiW1JB6uZ; Sun, 2 Aug 2009 15:16:02 -0700 (PDT) Received: from mail-px0-f185.google.com (mail-px0-f185.google.com [209.85.216.185]) by core3.amsl.com (Postfix) with ESMTP id DC1D43A680C; Sun, 2 Aug 2009 15:16:02 -0700 (PDT) Received: by pxi15 with SMTP id 15so1416222pxi.31 for ; Sun, 02 Aug 2009 15:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Gj0q613QDfMP3d20PdcuQ5sHTVM+bkPUPWCAE5kVwOA=; b=HzACKVkKkcV7TgYTO9PEFTC6jz7dVdveDu+ePCpMRzqVKWjzVtQozrhlSDKTPsNnWO aGH6lyPLJK1cxAclX353N7grwLdMxITdL6PlHCy5OE3HVjoljnQkuBjlMP+XTN/8R0ze MYX+ZMHDdSk58R3xq5udKcWxNHSBggHpvHHOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=gGhZg9fczDmg64gZ+54SGCMysX4wrMSVeeiGZLfbeWCyf0AQxr0r4m8VP0ITO9OgKi sgf3+grEkb9JK2uu9AACYrrRyzYjzoJDmkOho05UXubtZypYfTGuy6o054VApPQpAPsd prhTvWUoz4lLWF4DPmxKJYeMRj+KbrstURm0c= Received: by 10.141.2.13 with SMTP id e13mr3187807rvi.56.1249251363251; Sun, 02 Aug 2009 15:16:03 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c20sm31925195rvf.51.2009.08.02.15.16.00 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Aug 2009 15:16:02 -0700 (PDT) Message-ID: <4A76101E.7070207@gmail.com> Date: Mon, 03 Aug 2009 10:15:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> In-Reply-To: <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Aug 2009 22:16:03 -0000 Lars, It seems to me that it would not violate the spirit of RFC2460 if we added a rule that stacks MUST follow the RFC2460 rule by default but MAY deviate from it for duly configured tunnel end points in routers (where "router" is strictly as defined in section 2 of 2460 and the Note in that section). That would fully preserve the requirement as far as hosts and applications go. In fact, if draft-ietf-6man-node-req-bis is to become an Applicability Statement as we've discussed, that would be a fine document to define such a rule. Brian From tme@americafree.tv Sun Aug 2 15:31:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631FC3A6A4E; Sun, 2 Aug 2009 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmYM7Tio9vlw; Sun, 2 Aug 2009 15:31:07 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 8AED23A6A50; Sun, 2 Aug 2009 15:31:07 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D98D4463205A; Sun, 2 Aug 2009 18:31:09 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Brian E Carpenter In-Reply-To: <4A76101E.7070207@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 2 Aug 2009 18:31:08 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Aug 2009 22:31:08 -0000 Dear Brian; On Aug 2, 2009, at 6:15 PM, Brian E Carpenter wrote: > Lars, > > It seems to me that it would not violate the spirit of RFC2460 if > we added a rule that stacks MUST follow the RFC2460 rule by default > but MAY deviate from it for duly configured tunnel end points > in routers (where "router" is strictly as defined in section 2 > of 2460 and the Note in that section). That would fully preserve > the requirement as far as hosts and applications go. > This was exactly the intention of http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 We intend to rev this shortly and comments would be appreciated. Regards Marshall > In fact, if draft-ietf-6man-node-req-bis is to become an > Applicability Statement as we've discussed, that would be a fine > document to define such a rule. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From lars.eggert@nokia.com Mon Aug 3 01:32:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD1828C0EC; Mon, 3 Aug 2009 01:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuuZpivtHyAL; Mon, 3 Aug 2009 01:32:12 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5E9C828C0E1; Mon, 3 Aug 2009 01:32:12 -0700 (PDT) Received: from [192.168.0.198] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n738Vwao005854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Aug 2009 11:31:58 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <490C2B34-D7C7-4914-A2CF-3D7582D46A58@nokia.com> From: Lars Eggert To: Brian E Carpenter In-Reply-To: <4A76101E.7070207@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-10-398173802; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 11:31:53 +0300 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Mon, 03 Aug 2009 11:31:58 +0300 (EEST) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Aug 2009 08:32:13 -0000 --Apple-Mail-10-398173802 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-8-3, at 1:15, Brian E Carpenter wrote: > It seems to me that it would not violate the spirit of RFC2460 if > we added a rule that stacks MUST follow the RFC2460 rule by default > but MAY deviate from it for duly configured tunnel end points > in routers (where "router" is strictly as defined in section 2 > of 2460 and the Note in that section). That would fully preserve > the requirement as far as hosts and applications go. agreed, and this is what I've discussed with Dino and Joel in the hallway in Stockholm. My objection was about the LISP spec to unilaterally saying "we do something that conflicts with RFC2460" instead of getting community consensus for this variant. Lars --Apple-Mail-10-398173802 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDMwODMxNTNaMCMGCSqGSIb3DQEJBDEWBBQdZa9/ockBScD/ xrsjrAC/PfYSDTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAPUQLMim8+rpqj9qDiRPrZ0bSGVGwIjy3mX8wF0PlaWYwWFbinuxS +J7i1H6UZiEW6D8VGbeBUSYRkiCGMveLg6yrxOROQLzrQkvhZjnp5heRUn0ZUg297etTo9alppw2 Jo34VFt4VwJm2wKwhAAID8LE0P/qB+Kf0p+rCoSLb3+sHW1L1qvQ2G/pF8zCrQsJmN3sKSSjMOoG 6y2uZuJwlro6KHVI6aVT+sBjsRZ7qYyY3eDbBbgCIOwZUKREtJ3qjP+O/s/QtQAifk0GHk4bgSJo AinZ/lsqKzR5o1Ej4dCPKvejTEiRwYIwxAGscywmmGTnhSXdliEQpmDh2H8BMwAAAAAAAA== --Apple-Mail-10-398173802-- From mrw@lilacglade.org Mon Aug 3 13:19:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB2728C274 for ; Mon, 3 Aug 2009 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PadjGUXUSmNz for ; Mon, 3 Aug 2009 13:19:37 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 4DDE328C27B for ; Mon, 3 Aug 2009 13:19:18 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id PvxL1c0041GXsucAEwKFXh; Mon, 03 Aug 2009 20:19:15 +0000 Received: from lilac.sandstorm.net ([69.33.111.74]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id PwJw1c0051cMU3H8TwK1ur; Mon, 03 Aug 2009 20:19:13 +0000 Message-Id: <8795CE32-7CC2-46F3-B2E5-5617EC473D0F@lilacglade.org> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 16:18:54 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Aug 2009 20:19:38 -0000 Hi Dino, On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote: >> Hi, Dino, >> >> On 2009-7-29, at 14:02, Dino Farinacci wrote: >>> From a practical perspective, we prefer that a LISP encapsulator >>> (ITR >>> and PTR) not incurred additional work when encapsulating packets. >> >> could you share some data on how much of a performance impact we're >> talking about here? I was under the (maybe naive) impression that >> checksum offloading was practically ubiquitous these days. > > One of the problems with IPv6 is that is so similar to IPv4 but > different enough to cause pain for implementations. So since we can > use 0 UDP checksums for IPv4 in UDP in IPv4, we would want to build > (or use existing hardware) that does IPv6-or-IPv4 in UDP in IPv6. > > Reasons being (1) cost in building hardware, (2) chip area, (3) > power, (4) complexity, and (5) inconsistency from IPv4. > > This is only for encapsulated packets. This is for the outer header > only. The problem, as I see it, is that when you set the UDP checksum to 0 in IPv4 and IPv6, you aren't doing the same thing in both cases... In IPv4, there is an IP header checksum that protects the IP source and destination addresses. So, when you turn off UDP checksums in IPv4, you are only turning off checksums for the UDP header and the UDP payload (in this case, an encapsulated packet). You still need to calculate the IP header checksum. In IPv6, the only checksum for the IPv6 source and destination addresses is included in the UDP checksum (via the IPv6 pseudo-header checksum). So, when you turn off UDP checksums in IPv6, you are also turning off checksums for the IPv6 source and destination addresses. For cases where the payload is loss-tolerant and/or protected by a different mechanism, we have defined UDP-Lite, which allows you to calculate a checksum on the header fields only, not on the entire payload. This is not much more computational expensive than computing the IP header checksum for IPv4-encapsulated packets. So, we have two standards-compliant alternatives in IPv6 that would not require you to calculate a UDP checksum on the entire payload: (1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable choice for LISP encapsulation? When we looked into this for CAPWAP (another IP-in-UDP/IP tunneling case), we found that UDP-Lite would meet our needs for IPv6, so we did not need to specify the use of zero UDP checksums. (2) IP-in-IPv6: Why do you need the UDP encapsulation at all in IPv6? In IPv4, you may need it for NAT traversal, but it is not clear that NATs will work the same way in IPv6. Or are there other reasons why you need the UDP encapsulation? When you encapsulate IP in IPv6, you do not have a checksum that covers the outer IP header, so you would need to make sure that LISP is robust against corruption of the source and destination addresses. However, you do not have to worry as much about confusing non-LISP applications and/or corrupting their data, as there won't be a transport header there to misdeliver LISP packets to an unsuspecting application if the addresses and/or ports are corrupted. I personally think it is important to consider the standards-compliant choices before we decide to do something non-standards-compliant. FWIW, I agree that practical needs are very important. I am just not sure that we can't meet the practical needs with a standards-compliant solution. Margaret From menth@informatik.uni-wuerzburg.de Tue Aug 4 02:46:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8AB3A6EA1 for ; Tue, 4 Aug 2009 02:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1LpRqv3yQmm for ; Tue, 4 Aug 2009 02:46:38 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 57BA83A6FC7 for ; Tue, 4 Aug 2009 02:46:38 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C4E66A0790 for ; Tue, 4 Aug 2009 11:46:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B934BA078F for ; Tue, 4 Aug 2009 11:46:21 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9BCDAA078E for ; Tue, 4 Aug 2009 11:46:21 +0200 (CEST) Message-ID: <4A78036F.8070003@informatik.uni-wuerzburg.de> Date: Tue, 04 Aug 2009 11:46:23 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [lisp] Discussion about FIRMS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de 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, 04 Aug 2009 09:46:39 -0000 Dear colleagues, thanks a lot for your interest in FIRMS at the RRG meeting last Friday. We still had interesting discussions after the meeting and I'd like to share with you the outcome. http://www.ietf.org/proceedings/75/slides/RRG-1.pdf http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09-FIRMS.pdf 1) FIRMS: In case of cache misses at the ITR, packets can be forwarded as "data-probes" to a map-base which forwards them to the ETR. The map-bases can be located close to the ETR to minimize the extra delay due to path stretch. Joel's comment: it is not possible to place the map-base close to the ETRs. Michael: Yes, there are cases where this is difficult. For instance, when EIDs of a common prefix have different ETRs. Then, the map-base can be optimally placed only for a subset of them, or for all of them in a suboptimal way to minimize the path stretch compared to a direct route from ITR to ETR. In case that map-bases cannot be located near an ETR, the data-probes travel at least over a direct path from the ITR to the map-base which is not the case in many other proposals for mapping systems. This general problem does not exist with APT's default mapper (DM) because it has the mapping information in the source network. The DM is close to the source and can tunnel the packets directly to the ETRs so that only minimal path stretch occurs. However, all mappings are need to be available in the DM which leads to a large amount of data in the DMs. Moreover, updates are difficult because they need to be propagated to all DMs which takes relatively long time. In FIRMS, a map-base holds only a limited number of mappings and the mapping data need to be changed only in map-bases responsible for the respective EID-prefix. Hence, optimal forwarder placement, scalability, and fast updates seem to be conflicting goals. FIRMS gives more importance to the latter two. 2) Joel's concern was that ITRs may become lazy and forward most traffic over the mapping infrastructure so that delay due to path stretch matters. We think differently since the ITR's interest is to provide optimal service to the traffic which implies getting the mapping for a direct tunnel. In particular we think that initially increased packet delay is better than dropped packets. So far, these are opinions and the truth is probably application-dependent. 3) FIRMS does not use public infrastructure to carry map-requests. That statement during my presentation led to misunderstandings. FIRMS uses a hierarchical map-base pointer (MBP) distribution network consisting of MBP exchange nodes (MBPXs) to provide a copy of the MBP table to all map-resolvers. This MBP table tells the map-resolvers where the distributed map-bases are. Only little traffic is carried over the MBPXs and in particular no map-requests so that limited capacity is needed for public infrastructure. This is in contrast to other mapping systems in literature that we have reviewed in our paper. ALT is designed such that public network elements are completely avoided. However, this also raises the question of control (see next email). Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From menth@informatik.uni-wuerzburg.de Tue Aug 4 02:46:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA1B3A6FFB for ; Tue, 4 Aug 2009 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7rGKuREvawL for ; Tue, 4 Aug 2009 02:46:42 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CC6913A6FF7 for ; Tue, 4 Aug 2009 02:46:41 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4B4B519904E for ; Tue, 4 Aug 2009 11:46:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3EE8419905A for ; Tue, 4 Aug 2009 11:46:27 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 28B5B198E59 for ; Tue, 4 Aug 2009 11:46:27 +0200 (CEST) Message-ID: <4A780374.5040908@informatik.uni-wuerzburg.de> Date: Tue, 04 Aug 2009 11:46:28 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [lisp] Some questions about ALT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de 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, 04 Aug 2009 09:46:42 -0000 Dear colleagues, I have some questions about LISP+ALT since some pieces of that architecture are not yet clear to me. Either I have overlooked that information in the drafts or they are not yet publicly available. 1) The question of control Who has the control over ALT? Who decides what the aggregation points are? 2) Who's paying for the map-request traffic? In LISP+ALT, map-requests are carried over the ALT. In contrast, data traffic is carried over paths provided by "traditional BGP" for which intermediate carriers are obliged by contracts to carry the traffic. What are the incentives for providers to forward map-requests if they have no relations to the source or destination of that traffic. This situation seems possible or even likely to me for aggregation nodes. a) Does the ALT topology follow contract relationships like the normal BGP which possibly makes aggregation difficult? b) Will there be extra contracts to carry map-request traffic on the ALT`? c) Or will that work with mutual agreements since the overall rate of the map-request traffic is hopefully small enough to be carried without financial backing? Or is there another option? 3) The structure of the ALT and data-probes What are the guideline for designing the paths in the ALT? Business and trust relationships dominate the paths in the normal BGP. Aggregation should be the objective in the ALT, right? Can't that lead to extremely long paths when EID-prefix-aggregators on different levels are located in different areas? This adds to delay which is especially unfortunate for data-probes which are currently not considered in ALT. What was actually the reason to renounce on data-probes in the current version of LISP? 4) Resilience LISP+ALT uses ETRs as authoritative sources of the mappings and map-requests are delivered to them over the ALT. Multihomed networks have several ETRs which improve their availability. Which mechanism makes sure that map-requests are deviated to another ETR if the primary ETR fails? 5) Security Are there plans yet to add security in LISP+ALT? Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From iljitsch@muada.com Tue Aug 4 04:24:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E86928C333; Tue, 4 Aug 2009 04:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XLpYWdYuT6c; Tue, 4 Aug 2009 04:24:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0E98228C2DC; Tue, 4 Aug 2009 04:24:34 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74BO3kv041429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:24:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> From: Iljitsch van Beijnum To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 13:24:20 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 11:24:38 -0000 On 30 jul 2009, at 18:49, Margaret Wasserman wrote: > We need to consider what will happen if one of these packets is > received by a non-LISP node. Are you assuming that non-LISP stacks > will simply throw away these packets, because they have zero (and > therefore invalid) UDP checksums? That's only a good assumption if > we assume that LISP is the _only_ protocol that will allow the use > of zero checksums. The logic behind the UDP header in LISP is to allow effective ECMP load balancing. In IPv6 you don't need a UDP header for that, because you can hash on the flow label rather than port numbers. So no need for a UDP header -> no 0 checksums with LISP over IPv6. From iljitsch@muada.com Tue Aug 4 04:28:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10C628C360; Tue, 4 Aug 2009 04:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKUcK4Zay0Wq; Tue, 4 Aug 2009 04:28:27 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B210C28C35D; Tue, 4 Aug 2009 04:28:26 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74BS3AZ041458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:28:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 13:28:19 +0200 References: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 11:28:27 -0000 On 31 jul 2009, at 9:06, R=E9mi Denis-Courmont wrote: > Sounds like this would require a third datagram protocol number, that > is basically UDP except the checksum would only covering the IPv6 and > transport header. Hmmph, this is just like UDP-Lite really but it =20 > seems > like there is opposition to overloading UDP-Lite. Then the 64-=20 > translators > would convert it to normal UDP/IPv4... ? UDP ultra-lite: no length, no checksum, just port numbers.= From iljitsch@muada.com Tue Aug 4 04:40:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9585928C353; Tue, 4 Aug 2009 04:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdIti6cLdZIU; Tue, 4 Aug 2009 04:40:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6E76928C38C; Tue, 4 Aug 2009 04:39:24 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74Bd0jZ041573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:39:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <51D71D8B-BB6B-44AF-9B65-8F33999A666E@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200908040015.43375.remi@remlab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 13:39:17 +0200 References: <8C2160F1-2B13-40B9-AB71-398F7A48721C@sandstorm.net> <200908040015.43375.remi@remlab.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 11:40:15 -0000 I would be sorry to waste so much bandwidth, but it's your fault for coming up with these unworkable use cases: >> So, we have two standards-compliant alternatives in IPv6 that would >> not require you to calculate a UDP checksum on the entire payload: >> (1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable >> choice for LISP encapsulation? As I explained before, you don't need port numbers to load balance in IPv6 so no need for UDP here, light or otherwise. > You would expect 64-translators to convert UDP-Lite/IPv6 into UDP- > Lite/IPv4 > and back. Converting UDP-Lite/IPv6-with-8-bytes-coverage into UDP/ > IPv4- > without-checksum sounds hackish :( Then don't run LISP through an IPv4/IPv6 translator. It's not going to work anyway. From hartmans@mit.edu Tue Aug 4 06:09:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC683A68CE; Tue, 4 Aug 2009 06:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4ux2J17-0qb; Tue, 4 Aug 2009 06:09:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6C33028C342; Tue, 4 Aug 2009 06:08:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C06A51C3; Tue, 4 Aug 2009 09:08:32 -0400 (EDT) To: Marshall Eubanks References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> From: Sam Hartman Date: Tue, 04 Aug 2009 09:08:32 -0400 In-Reply-To: (Marshall Eubanks's message of "Sun\, 2 Aug 2009 18\:31\:08 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 13:09:43 -0000 >>>>> "Marshall" == Marshall Eubanks writes: Marshall> Dear Brian; Marshall> On Aug 2, 2009, at 6:15 PM, Brian E Carpenter wrote: > Lars, >> >> It seems to me that it would not violate the spirit of RFC2460 >> if we added a rule that stacks MUST follow the RFC2460 rule by >> default but MAY deviate from it for duly configured tunnel end >> points in routers (where "router" is strictly as defined in >> section 2 of 2460 and the Note in that section). That would >> fully preserve the requirement as far as hosts and applications >> go. >> This was exactly the intention of Marshall> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 Marshall> We intend to rev this shortly and comments would be Marshall> appreciated. Margaret brought up a set of questions for LISP if it's going to send 0 UDP checksums, basically surrounding what happens when a packet on such a tunnel is corrupted and gets received by a node that either does or does not understand the tunneling protocol. One of these questions hinged on the expected behavior of receivers seeing a 0 UDP checksum. I suggest that your draft 1) Indicate whether receivers should be specially configured to accept 0 checsums or whether all stacks should accept 0 checksums. 2) Adapt her questions as questions that IETF specs considering this exception need to answer to make sure that their protocol will work correctly in this mode. --Sam From hartmans@mit.edu Tue Aug 4 06:11:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BC528C3F4 for ; Tue, 4 Aug 2009 06:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if8Qr2aPNNrn for ; Tue, 4 Aug 2009 06:11:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7AAB428C381 for ; Tue, 4 Aug 2009 06:11:27 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2D46951C3; Tue, 4 Aug 2009 09:10:59 -0400 (EDT) To: menth@informatik.uni-wuerzburg.de References: <4A780374.5040908@informatik.uni-wuerzburg.de> From: Sam Hartman Date: Tue, 04 Aug 2009 09:10:59 -0400 In-Reply-To: <4A780374.5040908@informatik.uni-wuerzburg.de> (Michael Menth's message of "Tue\, 04 Aug 2009 11\:46\:28 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Some questions about ALT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 13:11:28 -0000 This sort of discussion is well within examining to what extent LISP is an operable/managable protocol. We try to avoid business process discussions within the IETF, but at least to the extent that they focus on whether something can be deployable, they definitely are in scope. From dromasca@avaya.com Tue Aug 4 06:20:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2678D3A6985 for ; Tue, 4 Aug 2009 06:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2mYnr8r-qm0 for ; Tue, 4 Aug 2009 06:20:36 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id E734E3A6FC4 for ; Tue, 4 Aug 2009 06:19:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,321,1246852800"; d="scan'208";a="169149702" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 Aug 2009 09:19:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Aug 2009 09:19:07 -0400 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: Tue, 4 Aug 2009 15:18:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Some questions about ALT thread-index: AcoVBRy/hQDM2oF2TmqB6FWY69W7xwAAPOgQ References: <4A780374.5040908@informatik.uni-wuerzburg.de> From: "Romascanu, Dan (Dan)" To: "Sam Hartman" , Cc: lisp@ietf.org Subject: Re: [lisp] Some questions about ALT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 13:20:37 -0000 +1 Dan =20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Sam Hartman > Sent: Tuesday, August 04, 2009 4:11 PM > To: menth@informatik.uni-wuerzburg.de > Cc: lisp@ietf.org > Subject: Re: [lisp] Some questions about ALT >=20 > This sort of discussion is well within examining to what=20 > extent LISP is an operable/managable protocol. We try to=20 > avoid business process discussions within the IETF, but at=20 > least to the extent that they focus on whether something can=20 > be deployable, they definitely are in scope. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From remi@remlab.net Mon Aug 3 14:15:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA46C3A6D5A; Mon, 3 Aug 2009 14:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgZ6EDlYED8i; Mon, 3 Aug 2009 14:15:49 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 409EF3A68A5; Mon, 3 Aug 2009 14:15:45 -0700 (PDT) Received: from basile.remlab.net (cs27060099.pp.htv.fi [89.27.60.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id E3665396; Mon, 3 Aug 2009 23:15:44 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: ipv6@ietf.org Date: Tue, 4 Aug 2009 00:15:42 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.30.4; KDE/4.2.4; i686; ; ) References: <8C2160F1-2B13-40B9-AB71-398F7A48721C@sandstorm.net> In-Reply-To: <8C2160F1-2B13-40B9-AB71-398F7A48721C@sandstorm.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908040015.43375.remi@remlab.net> X-Mailman-Approved-At: Tue, 04 Aug 2009 06:29:02 -0700 Cc: "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Aug 2009 21:15:50 -0000 Le lundi 3 ao=FBt 2009 23:17:10 Margaret Wasserman, vous avez =E9crit : (...) > So, we have two standards-compliant alternatives in IPv6 that would > not require you to calculate a UDP checksum on the entire payload: > > (1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable > choice for LISP encapsulation? When we looked into this for CAPWAP > (another IP-in-UDP/IP tunneling case), we found that UDP-Lite would > meet our needs for IPv6, so we did not need to specify the use of zero > UDP checksums. You would expect 64-translators to convert UDP-Lite/IPv6 into UDP-Lite/IPv4= =20 and back. Converting UDP-Lite/IPv6-with-8-bytes-coverage into UDP/IPv4- without-checksum sounds hackish :( > (2) IP-in-IPv6: Why do you need the UDP encapsulation at all in > IPv6? In IPv4, you may need it for NAT traversal, but it is not clear > that NATs will work the same way in IPv6. Or are there other reasons > why you need the UDP encapsulation? (...) Same problem. 64-translators would translate IP-in-IPv6 to IPIP and vice=20 versa. IPIP does not go through NATs. That's why I was trying to suggest defining a new UDP-Lite-like transport=20 protocol that would only be allowed over IPv6 and that 64-translator would= =20 convert into checksum-less UDP/IPv4. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From shane@castlepoint.net Tue Aug 4 07:24:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E463A6B93; Tue, 4 Aug 2009 07:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=1.736, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp-wTtSbqpNH; Tue, 4 Aug 2009 07:24:50 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 98A3D3A6BCF; Tue, 4 Aug 2009 07:24:49 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D1D0A2684EC; Tue, 4 Aug 2009 08:24:49 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 04 Aug 2009 08:24:49 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=58246; data-bytes=0 Message-Id: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> From: Shane Amante To: Iljitsch van Beijnum In-Reply-To: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 08:24:48 -0600 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 14:24:51 -0000 Iljitsch, On Aug 4, 2009, at 05:24 MDT, Iljitsch van Beijnum wrote: > On 30 jul 2009, at 18:49, Margaret Wasserman wrote: > >> We need to consider what will happen if one of these packets is >> received by a non-LISP node. Are you assuming that non-LISP stacks >> will simply throw away these packets, because they have zero (and >> therefore invalid) UDP checksums? That's only a good assumption if >> we assume that LISP is the _only_ protocol that will allow the use >> of zero checksums. > > The logic behind the UDP header in LISP is to allow effective ECMP > load balancing. In IPv6 you don't need a UDP header for that, > because you can hash on the flow label rather than port numbers. So > no need for a UDP header -> no 0 checksums with LISP over IPv6. The above assumes that a host actually imposes a flow-label on outgoing IPv6 packets. My understanding is that the flow-label isn't widely (if at all?) implemented, by default, in hosts; however, I would welcome corrections in my understanding with a list of host implementations that have the flow-label enabled by default. Second, I'll check around some more, but with respect to most routers I'm familiar with (particularly, MPLS LSR's that will be carrying IPv6 over MPLS inside a SP's ASN), they *also* don't use the IPv6 flow- label as an input key to calculate a hash to determine the outgoing component-link. However, they *do* currently use the Source and Destination Ports of the Transport Layer protocol as input keys to calculate a hash-key to determine the outgoing component-link/path. Since I don't work at these router vendors I can't explain the rationale for not using the flow-label as an input key to an ECMP or LAG load-balancing hash; however, I would suspect that if the flow- label isn't well-defined nor is it widely implemented in hosts, then it makes no sense for router vendors to try to include it in their hash-algorithms for ECMP/LAG load-balancing. So, in summary, I support UDP/IPvX encapsulation for LISP, (and other similar protocols that may appear as "macro-flows" in the core of a network), as it's the only well-known method, available today, for achieving load-balancing across ECMP or LAG paths that are widely deployed in today's networks and will continue to exist forever, (even with 100GE "just around the corner"). -shane > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tme@americafree.tv Tue Aug 4 07:30:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628283A6ABD; Tue, 4 Aug 2009 07:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuHVD1OUgi4X; Tue, 4 Aug 2009 07:30:13 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 5662C28C303; Tue, 4 Aug 2009 07:30:13 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id EC0F94669D88; Tue, 4 Aug 2009 10:30:11 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 10:30:11 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: "Philip F. Chimento" , 6man 6man , lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 14:30:14 -0000 On Aug 4, 2009, at 9:08 AM, Sam Hartman wrote: >>>>>> "Marshall" == Marshall Eubanks writes: > > Marshall> Dear Brian; > Marshall> On Aug 2, 2009, at 6:15 PM, Brian E Carpenter wrote: > >> Lars, >>> >>> It seems to me that it would not violate the spirit of RFC2460 >>> if we added a rule that stacks MUST follow the RFC2460 rule by >>> default but MAY deviate from it for duly configured tunnel end >>> points in routers (where "router" is strictly as defined in >>> section 2 of 2460 and the Note in that section). That would >>> fully preserve the requirement as far as hosts and applications >>> go. >>> > > This was exactly the intention of > > Marshall> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 > > Marshall> We intend to rev this shortly and comments would be > Marshall> appreciated. > > Margaret brought up a set of questions for LISP if it's going to send > 0 UDP checksums, basically surrounding what happens when a packet on > such a tunnel is corrupted and gets received by a node that either > does or does not understand the tunneling protocol. One of these > questions hinged on the expected behavior of receivers seeing a 0 UDP > checksum. > > > I suggest that your draft > > 1) Indicate whether receivers should be specially configured to accept > 0 checsums or whether all stacks should accept 0 checksums. > I personally think that receivers SHOULD require special configuration to accept UDP 0 checksums. Receivers that are acting as tunnel end points are likely to require special optimizations anyway. > 2) Adapt her questions as questions that IETF specs considering this > exception need to answer to make sure that their protocol will work > correctly in this mode. > OK, thanks, will look at this. Marshall > --Sam > From iljitsch@muada.com Tue Aug 4 07:52:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4696C3A706A; Tue, 4 Aug 2009 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo407i1JR+Fc; Tue, 4 Aug 2009 07:52:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 371F83A6BCF; Tue, 4 Aug 2009 07:52:42 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74Eq2px042948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 16:52:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> From: Iljitsch van Beijnum To: Shane Amante In-Reply-To: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 16:52:19 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 14:52:46 -0000 On 4 aug 2009, at 16:24, Shane Amante wrote: > The above assumes that a host actually imposes a flow-label on > outgoing IPv6 packets. It does not, it only requires the encapsulation boxes to do this. Since these don't exist yet, it's trivial to specify that they do this. I am unfortunately IPv6-less as of late, with first the university and then my ISP stopping their IPv6 service. As such I can't do a quick tcpdump to see how many sessions have a non-zero flow label. But I remember it's the vast majority. What I don't know is the behavior of the different operating systems, I'm mainly familiar with MacOS and FreeBSD, not sure what Linux and Windows do. > Second, I'll check around some more, but with respect to most > routers I'm familiar with (particularly, MPLS LSR's that will be > carrying IPv6 over MPLS inside a SP's ASN), they *also* don't use > the IPv6 flow-label as an input key to calculate a hash to determine > the outgoing component-link. Why not? > I would suspect that if the flow-label isn't well-defined nor is it > widely implemented in hosts, then it makes no sense for router > vendors to try to include it in their hash-algorithms for ECMP/LAG > load-balancing. The obvious solution in this case would be to use the flow label if available, and (either if the flow label isn't available or always) use the ports if those are available. That only leaves the situation where there is neither a flow label nor ports. > So, in summary, I support UDP/IPvX encapsulation for LISP It's still the wrong decision. From mrw@sandstorm.net Tue Aug 4 07:54:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CD63A7022; Tue, 4 Aug 2009 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdjNW+HSiNw4; Tue, 4 Aug 2009 07:54:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id A79B53A7082; Tue, 4 Aug 2009 07:54:17 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74EsGMC081491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 10:54:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <2DFFB758-97AA-4F1E-A10B-F520D973BD61@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <66F0C005-04F8-4F4F-9D79-28BF6229BDF1@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 10:54:15 -0400 References: <66F0C005-04F8-4F4F-9D79-28BF6229BDF1@cisco.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 04 Aug 2009 08:04:57 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 14:54:46 -0000 Hi Dino. > >> We also need to consider the possibility that a packet will be >> received by a different LISP node than the one for which it was >> intended, or that it will arrive at the correct LISP destination >> with the wrong source address in the external header. What happens >> in those cases? > > This doesn't happen since the outer IP header is checksum. Not if the outer header is IPv6, as the IPv6 header does not include a header checksum. This is why it is more important in IPv6 for the UDP header to have a checksum that includes the IP pseudo header checksum. If you have been missing this point, it is no wonder that you did not understand my concerns about simply setting the UDP checksum to zero. Margaret From mrw@sandstorm.net Tue Aug 4 08:00:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069A43A70A1; Tue, 4 Aug 2009 08:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6gH0AgOzjDg; Tue, 4 Aug 2009 08:00:42 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C6B7728C395; Tue, 4 Aug 2009 07:58:47 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74EwPxP081750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 10:58:26 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 10:58:25 -0400 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 04 Aug 2009 08:04:57 -0700 Cc: "ipv6@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 15:00:43 -0000 On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote: > >> What I'm saying is that *if* UDP us used, it needs to be used >> according to the RFCs that capture the IETF consensus on their use, >> or the IETF consensus must be revised. > > And what we are are saying is to be practical (and sensible). Well, what *I* am saying is that UDP-Lite was designed to offer a practical and sensible alternative for exactly these situations. Why won't it work for LISP? Margaret From jmh@joelhalpern.com Tue Aug 4 08:09:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07673A7076; Tue, 4 Aug 2009 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlY2isOhU1u7; Tue, 4 Aug 2009 08:09:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5E11F28C3C0; Tue, 4 Aug 2009 08:08:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D6DD437E4A; Tue, 4 Aug 2009 08:08:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 199FF4303F4; Tue, 4 Aug 2009 08:08:30 -0700 (PDT) Message-ID: <4A784EEF.2020405@joelhalpern.com> Date: Tue, 04 Aug 2009 11:08:31 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> In-Reply-To: <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 15:09:54 -0000 It has become clear with the passage of time that the description of the flow label in the original IPv6 specs served only to convince everyone not to use that field for anything. Even now, no one is sure what to do with it. To propose that encapsulators should use this field to mark the flows would seem reasonable. The problem is that since that was not done in the first place, as I understand it, router vendors concluded that the only sensible thing to do was to ignore the field, and do load balancing on ports just like we did on IPv4. Saying that we should have done it differently requires that the vendors be accurate fortune tellers, able to realize that the fields was going to turn out to be useful, and able to guess what usage they could safely make that would correctly match an eventual usage :-) And given the deployment assumptions, if we hope for LISP to be usable over IPv6, it can not depend for correct operation ona router feature that is not yet being delivered. (I will happily eat crow and apologize if it turns out routers already do what Iljitsch is asking for.) Yours, Joel Iljitsch van Beijnum wrote: > On 4 aug 2009, at 16:24, Shane Amante wrote: > >> The above assumes that a host actually imposes a flow-label on >> outgoing IPv6 packets. > > It does not, it only requires the encapsulation boxes to do this. Since > these don't exist yet, it's trivial to specify that they do this. > > I am unfortunately IPv6-less as of late, with first the university and > then my ISP stopping their IPv6 service. As such I can't do a quick > tcpdump to see how many sessions have a non-zero flow label. But I > remember it's the vast majority. What I don't know is the behavior of > the different operating systems, I'm mainly familiar with MacOS and > FreeBSD, not sure what Linux and Windows do. > >> Second, I'll check around some more, but with respect to most routers >> I'm familiar with (particularly, MPLS LSR's that will be carrying IPv6 >> over MPLS inside a SP's ASN), they *also* don't use the IPv6 >> flow-label as an input key to calculate a hash to determine the >> outgoing component-link. > > Why not? > >> I would suspect that if the flow-label isn't well-defined nor is it >> widely implemented in hosts, then it makes no sense for router vendors >> to try to include it in their hash-algorithms for ECMP/LAG >> load-balancing. > > The obvious solution in this case would be to use the flow label if > available, and (either if the flow label isn't available or always) use > the ports if those are available. That only leaves the situation where > there is neither a flow label nor ports. > >> So, in summary, I support UDP/IPvX encapsulation for LISP > > It's still the wrong decision. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From hartmans@mit.edu Tue Aug 4 08:29:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9843B28C403 for ; Tue, 4 Aug 2009 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDGVxSfCZQ3E for ; Tue, 4 Aug 2009 08:29:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id B7C5028C35D for ; Tue, 4 Aug 2009 08:29:57 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 79DC251C3; Tue, 4 Aug 2009 11:29:16 -0400 (EDT) To: lisp@ietf.org References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> From: Sam Hartman Date: Tue, 04 Aug 2009 11:29:16 -0400 In-Reply-To: (Margaret Wasserman's message of "Tue\, 4 Aug 2009 10\:58\:25 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 15:29:58 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote: >> >> What I'm saying is that *if* UDP us used, it needs to be used >>> according to the RFCs that capture the IETF consensus on their >>> use, or the IETF consensus must be revised. >> >> And what we are are saying is to be practical (and sensible). Margaret> Well, what *I* am saying is that UDP-Lite was designed Margaret> to offer a practical and sensible alternative for Margaret> exactly these situations. Why won't it work for LISP? Margaret> Margaret _______________________________________________ Margaret> lisp mailing list lisp@ietf.org Margaret> https://www.ietf.org/mailman/listinfo/lisp And While we're all *saying* things, I as chair am *saying* that at the end of this discussion we're going to document it.:-) Assuming that the current LISP behavior does not change, it sounds like we have the following to document: 1) Add a normative reference to some standards-track or BCP document that makes our behavior permissible. In that document or in the LISP spec: 2) Document why you'd use UDP, not IPIP or udp-light. 3) Answer Margaret's questions about what the effects of packet corruption are. That probably belongs in the LISP spec. 4) If there are changes that seem sensible for the IPV6 community to consider long-term, write them up and suggest them to 6man|intarea as appropriate. From iljitsch@muada.com Tue Aug 4 08:46:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797DE28C3C0; Tue, 4 Aug 2009 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av-Mia8bQkvC; Tue, 4 Aug 2009 08:46:41 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8756828C3AA; Tue, 4 Aug 2009 08:46:41 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74FkCrw043560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 17:46:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <088E2F9F-7527-4577-AB18-B1505DB49205@muada.com> From: Iljitsch van Beijnum To: "Joel M. Halpern" In-Reply-To: <4A784EEF.2020405@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 17:46:29 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 15:46:42 -0000 On 4 aug 2009, at 17:08, Joel M. Halpern wrote: > And given the deployment assumptions, if we hope for LISP to be > usable over IPv6, it can not depend for correct operation ona router > feature that is not yet being delivered. I am really starting to lose my patience here!!! Even IF existing implementations don't put any value in the flow label, the LISP spec can specify that this MUST be done for LISP and then there will be flow labels in all LISP packets. Obviously it will take some time for the router implementations to start hashing on the flow label, but then again, it will also take some time for the traffic from a single ITR to a single ETR (or the other way around, whatever) to need more than 1 Gbps so the load balancing issue becomes more than academic. Come on, people! If we can't even get stuff right in fairly green fields, how can we expect to get ANYTHING right EVER?? From tme@americafree.tv Tue Aug 4 08:57:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7113428C254 for ; Tue, 4 Aug 2009 08:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv1pd+t-67ea for ; Tue, 4 Aug 2009 08:57:54 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 7F9DE3A6B56 for ; Tue, 4 Aug 2009 08:57:54 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 87646466C0AD; Tue, 4 Aug 2009 11:57:51 -0400 (EDT) Message-Id: <8766AD1A-3159-414A-9392-26CB5DBE4E25@americafree.tv> From: Marshall Eubanks To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 11:57:50 -0400 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 15:57:55 -0000 On Aug 4, 2009, at 11:29 AM, Sam Hartman wrote: >>>>>> "Margaret" == Margaret Wasserman writes: > > Margaret> On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote: >>> >>> What I'm saying is that *if* UDP us used, it needs to be used >>>> according to the RFCs that capture the IETF consensus on their >>>> use, or the IETF consensus must be revised. >>> >>> And what we are are saying is to be practical (and sensible). > > Margaret> Well, what *I* am saying is that UDP-Lite was designed > Margaret> to offer a practical and sensible alternative for > Margaret> exactly these situations. Why won't it work for LISP? > > Margaret> Margaret _______________________________________________ > Margaret> lisp mailing list lisp@ietf.org > Margaret> https://www.ietf.org/mailman/listinfo/lisp > > And While we're all *saying* things, I as chair am *saying* that at > the end of this discussion we're going to document it.:-) > > > Assuming that the current LISP behavior does not change, it sounds > like we have the following to document: > > 1) Add a normative reference to some standards-track or BCP document > that makes our behavior permissible. > I think that that should be to http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 assuming 6man adopts it. > In that document or in the LISP spec: > > 2) Document why you'd use UDP, not IPIP or udp-light. > > 3) Answer Margaret's questions about what the effects of packet > corruption are. That probably belongs in the LISP spec. > I think it should be in the UDP Checksum document. > 4) If there are changes that seem sensible for the IPV6 community to > consider long-term, write them up and suggest them to 6man|intarea as > appropriate. > We are updating (a piece) of RFC2460. Does there need to be more ? Regards Marshall > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From hartmans@mit.edu Tue Aug 4 09:12:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA7C3A7022 for ; Tue, 4 Aug 2009 09:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ4G4ydJgbvu for ; Tue, 4 Aug 2009 09:12:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 0EF8C3A6FC4 for ; Tue, 4 Aug 2009 09:12:42 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D759A51C3; Tue, 4 Aug 2009 12:12:22 -0400 (EDT) To: Marshall Eubanks References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> <8766AD1A-3159-414A-9392-26CB5DBE4E25@americafree.tv> From: Sam Hartman Date: Tue, 04 Aug 2009 12:12:22 -0400 In-Reply-To: <8766AD1A-3159-414A-9392-26CB5DBE4E25@americafree.tv> (Marshall Eubanks's message of "Tue\, 4 Aug 2009 11\:57\:50 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 16:12:43 -0000 > 3) Answer Margaret's questions about what the effects of packet > corruption are. That probably belongs in the LISP spec. > Marshall> I think it should be in the UDP Checksum document. That would be fine if you can make it work. The problem I see is that it seems quite LISP specific to me. Margaret was asking for example what would happen if the source address is corrupted and a control/data packet reached a valid LISP ETR but with a different source address. How does this deal with various caches etc? In other words, Margaret is asking the LISP community to document the effects of LISP over IPV6 with no integrity proection for the LISP tunneling. I think there are certain aspects of this that are generic: the data packet will presumably make its way to some destination where it will be discarded if the data packet is corrupted and accepted if the corruption only affects the outer part of the packet. However, it seems like aspects of this are also specific to the tunneling mechanism. > 4) If there are changes that seem sensible for the IPV6 community to > consider long-term, write them up and suggest them to 6man|intarea as > appropriate. Marshall> > Marshall> We are updating (a piece) of RFC2460. Does there need to be more ? Need? Absolutely not. However there have been side discussions surrounding lots of things including how best to do ECMP, etc, etc. If any of those side discussions reach conclusions, then they should be sent somewhere that can act on them. From hartmans@mit.edu Tue Aug 4 09:47:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BF53A6A2E; Tue, 4 Aug 2009 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGCU-yqdNlDD; Tue, 4 Aug 2009 09:47:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 3120F3A69A8; Tue, 4 Aug 2009 09:47:33 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E90C051C3; Tue, 4 Aug 2009 12:47:09 -0400 (EDT) To: "Joel M. Halpern" References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> From: Sam Hartman Date: Tue, 04 Aug 2009 12:47:09 -0400 In-Reply-To: <4A784EEF.2020405@joelhalpern.com> (Joel M. Halpern's message of "Tue\, 04 Aug 2009 11\:08\:31 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 16:47:34 -0000 >>>>> "Joel" == Joel M Halpern writes: Joel> It has become clear with the passage of time that the Joel> description of the flow label in the original IPv6 specs Joel> served only to convince everyone not to use that field for Joel> anything. Even now, no one is sure what to do with it. Joel> To propose that encapsulators should use this field to mark Joel> the flows would seem reasonable. The problem is that since Joel> that was not done in the first place, as I understand it, Joel> router vendors concluded that the only sensible thing to do Joel> was to ignore the field, and do load balancing on ports just Joel> like we did on IPv4. IPV6 deployment is fairly low. It seems likely that most of the equipment that will be used to forward IPV6 traffic has not yet been built, and that while we definitely need to work with today's equipment, I think it is safe to say that 10, 15, 20 years from now, the things we optimize for will be different. so, if we find new best practices for encapsulators today, we should write them down, try them out and build consensus. That way, 3-4 years from now we may be in a position to recommend forwarders do something different and 10-15 years from now, rely on that Naturally, any such discussion should have a sufficiently broad audience to be useful. From iljitsch@muada.com Tue Aug 4 11:39:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF163A6F25; Tue, 4 Aug 2009 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDwECxiJApwk; Tue, 4 Aug 2009 11:39:41 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 31FD63A6DC1; Tue, 4 Aug 2009 11:39:10 -0700 (PDT) Received: from [192.168.2.9] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74IcmRN045105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 20:38:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <65A14E2C-9662-44C5-B7F8-F71170B9FD53@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 20:39:04 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <65A14E2C-9662-44C5-B7F8-F71170B9FD53@free.fr> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue - Flowlabel use already specified X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 18:39:42 -0000 On 4 aug 2009, at 19:57, R=E9mi Despr=E9s wrote: > RFC 3697, which is on standards track, specifies how to use =20 > flowlabels. > I would personally have no objection to it's deprecation, but it's =20 > here. Since apparently nobody looks at it today, I'm tempted to attempt to =20 scavenge some header bits there. For re-ecn we need one bit and I =20 could use three or so as a path selector for path selection in =20 multipath TCP...= From remi@remlab.net Tue Aug 4 12:13:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC053A6AF1; Tue, 4 Aug 2009 12:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QfZ1vTiLE8N; Tue, 4 Aug 2009 12:13:32 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id B45EC3A68AF; Tue, 4 Aug 2009 12:13:32 -0700 (PDT) Received: from basile.remlab.net (cs27060099.pp.htv.fi [89.27.60.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id EA4F7396; Tue, 4 Aug 2009 21:13:29 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: Margaret Wasserman Date: Tue, 4 Aug 2009 22:13:27 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.30.4; KDE/4.2.4; i686; ; ) References: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> <10223B44-6C4E-4A81-B5CE-86B4BE13B3A2@sandstorm.net> In-Reply-To: <10223B44-6C4E-4A81-B5CE-86B4BE13B3A2@sandstorm.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908042213.28367.remi@remlab.net> Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:13:34 -0000 Le mardi 4 ao=FBt 2009 22:01:01 Margaret Wasserman, vous avez =E9crit : > On Jul 31, 2009, at 3:06 AM, R=E9mi Denis-Courmont wrote: > > is basically UDP except the checksum would only covering the IPv6 and > > transport header. Hmmph, this is just like UDP-Lite really but it > > seems > > like there is opposition to overloading UDP-Lite. Then the 64- > > translators > > would convert it to normal UDP/IPv4... ? > > Why do you think that this would be "overloading UDP-Lite"? Gorry Fairhurst does, not me. UDP-Lite was specified for damage-tolerant=20 payloads, not to avoid redumdant checksums. Personally, I don't care. > And what is the opposition? The only (valid) argument that I remember against UDP-Lite was lack of=20 compatibility with IPv4 NAT/firewall in case the flow would go through a=20 NAT64. This was a comment from Dave Thaler in SF. Admittedly, it was about= =20 AMT, not LISP. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From tme@americafree.tv Tue Aug 4 13:57:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B2C3A6992; Tue, 4 Aug 2009 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8haaN88eQqr; Tue, 4 Aug 2009 13:57:58 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6C1043A6A00; Tue, 4 Aug 2009 13:57:58 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id AFFDA4673313; Tue, 4 Aug 2009 16:58:00 -0400 (EDT) Message-Id: <79AC222F-950D-4210-B906-CAE37770B071@americafree.tv> From: Marshall Eubanks To: Margaret Wasserman In-Reply-To: <41CC608D-E261-4CD8-A22E-86FCFEE220FD@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 16:57:59 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <41CC608D-E261-4CD8-A22E-86FCFEE220FD@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: "Philip F. Chimento" , 6man 6man , lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 20:57:59 -0000 Dear Margaret; Thank you for this long list of issues/questions. They will be addressed. Regards Marshall On Aug 4, 2009, at 3:37 PM, Margaret Wasserman wrote: > > On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote: >> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 >> >> We intend to rev this shortly and comments would be appreciated. > > If you do rev this document, I would like to see: > > (1) An explanation of the difference in applicability between this > mechanism > and UDP-Lite. > > (2) A specific applicability statement for when this mechanism can > (and can't) > be used. Would we be allowing this mechanism _only_ for cases > where > IP is tunneled inside UDP/IP? What about the AMT case? > > (3) A section listing considerations that must be documented for > protocols > that use this mechanism, including: > > (3a) What happens when the destination IP address is corrupted in > transit? > (Note: This isn't a concern in IPv4, as the IP header > checksum will result > in this packet being discarded by the receiving IP stack). > > (3a.i) What if a node that does not implement this protocol > receives the > packet? > (3a.ii) What if a node that does implement this protocol > receives a packet > destined for another node? > > (3b) What happens when the source IP address is corrupted in > transit? > (Note: This isn't a concern in IPv4, as the IP header > checksum will result > in this packet being discarded by the receiving IP stack). > > (3b.i) What happens when a node that does not implement this protocol > receives the ICMP "port unreachable" error? > (3b.ii) What happens when a node that does implement this > protocol > receives an ICMP "port unreachable" error for a > packet it didn't send? > > (3c) What happens if one or both of the UDP ports are corrupted > in transit? > (Note: This can happen in IPv4 in the zero checksum > case, too, but not > with UDP checksums turned on and/or UDP-Lite). > > (3d) What types of middleboxes does the protocol need to cross > (routers, > NAT boxes, firewalls, etc.), and how will those > middleboxes deal with > these packet > > I don't really have enough knowledge to answer these questions for > LISP. I > tried to go down this path in an earlier message, and Dino didn't > understand what > I was saying, but I'll try to do it once again. Please correct me > if I am missing > something. > > I am making the assumption that (unlike AMT), all LISP packets will > be sent to > a specific UDP port assigned to LISP. Also, I am making the > assumption that > if we write this document, some other protocols (besides LISP) will > make use of > it, so some IP stacks on non-LISP nodes will process these packets. > > (3a.i) If a node that doesn't implement LISP receives this packet, > it may be > passed up to UDP (if zero checksums are supported). At > that point, > though, it will be thrown away because there is no process > listening > on the LISP port and an ICMPv6 "port unreachable" error > will be > generated. (This is different than the IPv4 case, where > the packet > will never make it to UDP). > > (3a.ii) If a node that does implement LISP receives this packet, it > will be > sent to the LISP process, which will recognize that it is an > encapsulated LISP packet. What then? (Note: Again, this > wouldn't happen in IPv4, as the packet would be discarded by > the receiving IP stack.). > > (3b.i) If a node that doesn't implement LISP receives an ICMP port > unreachable for the LISP port, it may have a process that is > using the local port from the original LISP packet. Will > that > process receive the destination unreachable? Or will the > message be thrown away because the destination port doesn't > match? I think this might depend on how the process was > bound to its socket, or something. Can someone help me > out here? (Note: This won't happen in IPv4, because the > packet would have been discarded by IP, not by UDP). > > (3b.ii) If a node that does implement LISP receives an ICMP port > unreachable, it still might not have a process that is using > the corresponding source port (right?). In that case, I > think > that this is the same as 3b.i... Would another process > receive this error? And, if so, how would it respond? > > (3c) If the ports were corrupted in transit, we might get packets > delivered to the wrong process (on the right machine) > and/or responses or errors sent to the wrong process (on > the right machine). I think this all would have been covered > by the above cases. > > (3d) I don't know how middleboxes will deal with this... What > do IPv6 routers do today with zero-checksum UDP packets? > What other IPv6 middleboxes exist today, and what would > they do? > > Personally, I think this is something we would need to understand > pretty fully before we could decide that turning off IPv6 UDP > checksums > is a superior choice to using IP-in-IPv6 encapsulation (no UDP), > IP-in-IPv6/UDP-Lite encapsulation or UDP with checksums. > > These are also areas that we should explore in a general sense before > we decide to publish Marshall's document as an alternative to using > IP-in-IPv6 encapsulation, UDP-Lite, or UDP with checksums. > > Margaret > > > > > From brian.e.carpenter@gmail.com Tue Aug 4 15:10:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA01C28C239; Tue, 4 Aug 2009 15:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bMD+4LzkdoO; Tue, 4 Aug 2009 15:10:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id C39B528C3B7; Tue, 4 Aug 2009 15:09:55 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1155628rvb.49 for ; Tue, 04 Aug 2009 15:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=H0T0xLQYovbBwYPhXWoaeQk0+QTxWWWWgwH22p6L1ZY=; b=KDpfJbnoJL7Syd5KtUoKPro8h2voacvsrB4JhzJ3sTK07UPXITAWkpd2TO5Va0JwnU glpbxT9VEU7pqJwBpjw7GBM/GiTzyQrNQCpG3qoBphHQdCkCmCW/I3Wv3fOU8QyjnKkg TnBcs0AwsnJw/XWyo8oFbS35UqFrN9Jsdub8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=djdbr67yjBphcoJlbbDatKmZGMjIl5PkqNFEvp4PwDjSK2BxBA0RACUlQgOPYWkCsg 0izpsAbhQBVRxQyZyjkgrpkHMoFa2QWGE3U8BPMo2i6fSleSB44nc30UOD+/iTVxwe/b 3s35h1lYO23il7F5BdASWEl6e9x1z8ZGFW4vM= Received: by 10.141.12.15 with SMTP id p15mr5663387rvi.41.1249423796647; Tue, 04 Aug 2009 15:09:56 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b39sm4333143rvf.43.2009.08.04.15.09.54 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 15:09:55 -0700 (PDT) Message-ID: <4A78B1B0.50201@gmail.com> Date: Wed, 05 Aug 2009 10:09:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <65A14E2C-9662-44C5-B7F8-F71170B9FD53@free.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue - Flowlabel use already specified X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 22:10:05 -0000 On 2009-08-05 06:39, Iljitsch van Beijnum wrote: > On 4 aug 2009, at 19:57, R=C3=A9mi Despr=C3=A9s wrote: >=20 >> RFC 3697, which is on standards track, specifies how to use flowlabels= =2E >> I would personally have no objection to it's deprecation, but it's her= e. >=20 > Since apparently nobody looks at it today, I'm tempted to attempt to > scavenge some header bits there. For re-ecn we need one bit and I could= > use three or so as a path selector for path selection in multipath TCP.= =2E. That's not so easy. The bits aren't up for grabs and they aren't microcod= ed like the Traffic Class bits (which is why ECN was possible in the first place). It may be entirely possible to devise a use case that falls withi= n RFC3697 where you could encode some bits; that RFC was very carefully written to allow a very wide variety of uses. In fact the only real rule, when you come down to it, is that the 20 bits must be delivered exactly as sent. Pretty much everything else is allowed if you use the MAYs and SHOULDs creatively. Brian From brian.e.carpenter@gmail.com Tue Aug 4 15:24:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243B13A70F6; Tue, 4 Aug 2009 15:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YcW+PGnKjp9; Tue, 4 Aug 2009 15:24:37 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id CD16828C3E7; Tue, 4 Aug 2009 15:24:32 -0700 (PDT) Received: by pzk8 with SMTP id 8so2961353pzk.31 for ; Tue, 04 Aug 2009 15:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GFhUEMpfMKfcWX5ErpXg/Ob87ZCc7Zcmi9kPEl89xlU=; b=XO6/NrpiV80rex4LHBrxWquHjV2EUPO9eiwQo6tuT31S+AiMh5HxxlV657d7SBPaWZ mxecMD0PaHdlnHbkXvasOvyMxuTIkbeNIWxwQxCBLgArIVnnje/dO8+AdtOBrgD7OB5f z4IbluKCI+sQxaCLN6ZqQxsQk6nqwz5SoiEFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=HoCnQnOddCAnbZ1DAilX4S+yCfKRQvEvD2460RunWjO/m+5jNMrLYQdm2WCFIEWMVT hSkIbi0816s38LlR5w/c/t5Cro9nu7oGgf0z8eJzJk9ZRNdMV1xqmT0uNArtcMf/E71+ xTULV0iGDXYatjuqaQZ2mxU7LNBbVkbKdkoRU= Received: by 10.115.54.2 with SMTP id g2mr9380839wak.160.1249424673548; Tue, 04 Aug 2009 15:24:33 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id m6sm12321124wag.68.2009.08.04.15.24.30 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 15:24:32 -0700 (PDT) Message-ID: <4A78B51C.2010902@gmail.com> Date: Wed, 05 Aug 2009 10:24:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> In-Reply-To: <4A784EEF.2020405@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 22:24:38 -0000 Hi Joel, On 2009-08-05 03:08, Joel M. Halpern wrote: > It has become clear with the passage of time that the description of the > flow label in the original IPv6 specs served only to convince everyone > not to use that field for anything. Even now, no one is sure what to do > with it. If you're referring to the lame appendix to RFC2460, that's exactly why we wrote RFC3697. My understanding is that some stacks do set the flow label according to the SHOULD in RFC3697, but I'm not aware of any deployed use cases (such as load balancing routers). The gap is not in the basic specs but in exploitation. It's very similar to what happened with the IPv4 TOS byte, and that took 20 years before we (a) defined it properly and (b) began to see limited deployment, as corporate VoIP took off. My expectation has always been that exploitation of the flow label would stay on the back burner until IPv6 deployment reached a significant level, because there isn't much benefit in optimising flow handling for <1% of the traffic. So I don't really see anything odd in the current situation. That said, I can't see any reason why ITRs and ETRs can't use the flow label among themselves, in a way completely compatible with RFC3697. But if their hardware engines can't include the flow label in the n-tuple, that's a problem. Brian From vaf@cisco.com Tue Aug 4 16:32:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B586B3A70FC; Tue, 4 Aug 2009 16:32:24 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux+tItOsbAjU; Tue, 4 Aug 2009 16:32:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F1FF33A70EA; Tue, 4 Aug 2009 16:32:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGFheEqrR7MV/2dsb2JhbAC8FogpkBoFhBiBUQ X-IronPort-AV: E=Sophos;i="4.43,324,1246838400"; d="scan'208";a="223453092" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2009 23:32:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n74NWQsx026036; Tue, 4 Aug 2009 16:32:26 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n74NWQEe028800; Tue, 4 Aug 2009 23:32:26 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n74NQmHS026236; Tue, 4 Aug 2009 16:26:48 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n74NQmDj026233; Tue, 4 Aug 2009 16:26:48 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 4 Aug 2009 16:26:48 -0700 From: Vince Fuller To: Brian E Carpenter Message-ID: <20090804232648.GA18233@vaf-lnx1> References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A78B51C.2010902@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1134; t=1249428746; x=1250292746; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[lisp]=20Flow=20label=20redux=20[Re=3A= 20=20IPv6=20UDP=20checksum=20issue] |Sender:=20; bh=yvFjkqr9hbl1EAzn7KJsNkW3kYmO0sna19CegpjGfw4=; b=m+d2DpS+BkWzJMgDFwbK26+cevbQmsY2MP0xfDPw4970ShCBtzQ4X/W/FS dkIzyzoJgnbM0NHccWk4smUQ2eaUpnwrOM8nVTcwnbgFxLlUwMQQTNNbndAQ tTTNXIuY3rbNYr/BQQJQQGrR948FtQDj/SLQ3nPNVEn3a1UjTb2j0=; Authentication-Results: sj-dkim-1; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 23:32:24 -0000 > That said, I can't see any reason why ITRs and ETRs can't use > the flow label among themselves, in a way completely compatible > with RFC3697. But if their hardware engines can't include the > flow label in the n-tuple, that's a problem. The issue isn't whether the "hardware engines can't include the flow label in the n-tuple" on the ITRs/ETRs; since LISP is implemented on ITRs and ETRs, we have no problem specifying their behavior. The issue is how to effect load-splitting across Link Aggregation Groups (LAGs) in all of the non-LISP-aware transit routers on the Internet through which LISP-encapsulated traffic will flow. Current operational reality is that the installed base of transit routers on the Internet uses a hash of source/dest addres/port to split traffic across LAGs so LISP uses an encapsulation that is compatible with that reality. Specifying some alternate reality and hoping that the operational world will modify its behavior to match doesn't seem very practical, particularly since one of LISP's virtues is that it requires no changes to the transit routing system. --Vince From mrw@lilacglade.org Tue Aug 4 17:55:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4967F28C407 for ; Tue, 4 Aug 2009 17:55:07 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OqRzQ-pZlnG for ; Tue, 4 Aug 2009 17:55:06 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 30ED528C47D for ; Tue, 4 Aug 2009 17:54:08 -0700 (PDT) Received: from OMTA23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA01.westchester.pa.mail.comcast.net with comcast id QPhc1c00P1c6gX851QuCsw; Wed, 05 Aug 2009 00:54:12 +0000 Received: from [10.36.0.42] ([173.76.25.94]) by OMTA23.westchester.pa.mail.comcast.net with comcast id QQwf1c00B21osJt3jQwiLn; Wed, 05 Aug 2009 00:56:55 +0000 Message-Id: <4EFCBD42-BCF0-4B60-9B50-6F355DD03534@lilacglade.org> From: Margaret Wasserman To: byzek In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 20:53:53 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 00:55:07 -0000 Hi Byzek, On Jul 30, 2009, at 8:31 PM, byzek wrote: > > It's not about performance; a large percentage of the currently-=20 > deployed > hardware can=92t do UDP checksum calculations during encapsulation =20 > because it > doesn=92t have access to the entire packet. Most hardware is =20 > streamlined to > only provide the first n bytes of a packet to the forwarding engine, =20= > where > typically n < 128. This is one of the primary reasons, as I understood it, why UDP-Lite =20 was defined the way it was -- to allow for a transport-layer checksum, =20= including an IP pseudo-header checksum, in IPv6, without the need to =20 traverse the entire packet. In the LISP case, all of the bytes that =20 would need to be "checksummed" for UDP-Lite would be bytes that were =20 _added to the packet_ by the LISP encapsulating router. When an IPv4/UDP header is pre-pended by a LISP router, the lisp ETR =20 needs to calculate the IP header checksum over 20 bytes (the IP header). If an IPv6/UDP-Lite header were pre-pended by a LISP router, the ETR =20 would need to calculate an IP header checksum over 48 bytes (the IP =20 pseudo-header and the UDP header). While I understand that 48 bytes is larger than 20 bytes, we aren't =20 really talking about a major difference when the checksum algorithm is =20= well-optimized and all of the pre-pended header bytes are already in =20 memory. Margaret From mrw@lilacglade.org Tue Aug 4 18:00:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9468028C47F for ; Tue, 4 Aug 2009 18:00:19 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD3Jyh246iUX for ; Tue, 4 Aug 2009 18:00:18 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id BFAD228C468 for ; Tue, 4 Aug 2009 18:00:18 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id QQPE1c0060QkzPwA5R0N9M; Wed, 05 Aug 2009 01:00:22 +0000 Received: from [10.36.0.42] ([173.76.25.94]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id QR071c00E21osJt8NR0A4i; Wed, 05 Aug 2009 01:00:20 +0000 Message-Id: <83A588D4-6066-4148-A313-8344DE77CA0E@lilacglade.org> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090730233310.4A4EB6BE591@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 21:00:05 -0400 References: <20090730233310.4A4EB6BE591@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 01:00:19 -0000 Hi Noel, On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote: > > Dino, why don't we just drop the 'inside IPv6' encapsulations from > the spec? > I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6 > encapsulations could be > documented in a short non-IETF note that's posted on a personal web > page > somewhere. (I'm assuming here that there are a few ISPs who'd > actually want to > run inside IPv6, otherwise we could just drop them entirely.) To drop the encapsulation in IPv6, you'd need to get LISP WG consensus to do so. Personally, I would not agree with that choice. Margaret From brian.e.carpenter@gmail.com Tue Aug 4 19:09:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC54E28C493; Tue, 4 Aug 2009 19:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oafYqL71Pp58; Tue, 4 Aug 2009 19:09:56 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id D94743A696F; Tue, 4 Aug 2009 19:09:56 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1187488rvb.49 for ; Tue, 04 Aug 2009 19:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UNQ0r4NPIko7Nva/ICviDRCaIGCXFHLsEy+5RvOrfPg=; b=QIUxCFix+QMBgqbVHg7B7ICyAiUEX4LCzumvJpi2LGh/O/sG3AYT2fkdsU1r+/8FjU BhfHAhPlDP8RUNNZ0JXmZM5841vvelNnzGgiy/vh2BkOLCBdV4Cwq/3a1T7pVhK7aHct ttmHReOdh858j0taCpqUz9r1dGBe77RSW1cYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=AnDdtus/IarSaKQZCoevnG/K1pZGlHpTD9BvasccH3tpmoDmm/SjA+brphRSyYBU68 wn0ETBhWc1LbQGfdrTl32+pZ/wJSpjGYG9X9EgGFrKuqa4RTCuVfGFuI003APMrdlGP2 tiEwgVBJ3zwYXrlqeLNlYwjbL9KGDj2pc69ls= Received: by 10.140.144.6 with SMTP id r6mr5970247rvd.114.1249438182562; Tue, 04 Aug 2009 19:09:42 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g22sm5376581rvb.48.2009.08.04.19.09.40 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 19:09:41 -0700 (PDT) Message-ID: <4A78E9F0.4070005@gmail.com> Date: Wed, 05 Aug 2009 14:09:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vince Fuller References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <20090804232648.GA18233@vaf-lnx1> In-Reply-To: <20090804232648.GA18233@vaf-lnx1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 02:09:57 -0000 On 2009-08-05 11:26, Vince Fuller wrote: >> That said, I can't see any reason why ITRs and ETRs can't use >> the flow label among themselves, in a way completely compatible >> with RFC3697. But if their hardware engines can't include the >> flow label in the n-tuple, that's a problem. > > The issue isn't whether the "hardware engines can't include the flow label > in the n-tuple" on the ITRs/ETRs; since LISP is implemented on ITRs and ETRs, > we have no problem specifying their behavior. > > The issue is how to effect load-splitting across Link Aggregation Groups > (LAGs) in all of the non-LISP-aware transit routers on the Internet through > which LISP-encapsulated traffic will flow. > > Current operational reality is that the installed base of transit routers > on the Internet uses a hash of source/dest addres/port to split traffic > across LAGs so LISP uses an encapsulation that is compatible with that > reality. Sure. But IMHO the LISP design should not be restrictive. It should be possible by design to change the fields used for the hash if the operational reality changes in the future. (In fact, one of the motivations for the exact choices made in RFC3967 was to make it possible to include the flow label in such a hash without knowing what sort of usage, if any, was being made of the flow label. And I see no particular issue with a network where some LAG-aware routers do include the flow label in the hash and others don't.) > > Specifying some alternate reality and hoping that the operational world will > modify its behavior to match doesn't seem very practical, particularly since > one of LISP's virtues is that it requires no changes to the transit routing > system. Well understood. But future-proofing is rarely an error. Brian From jmh@joelhalpern.com Tue Aug 4 19:51:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A393A6F76; Tue, 4 Aug 2009 19:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLuyvVE0Q92Y; Tue, 4 Aug 2009 19:51:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E41943A6887; Tue, 4 Aug 2009 19:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EB911438012; Tue, 4 Aug 2009 19:51:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id EF8A7437E53; Tue, 4 Aug 2009 19:51:50 -0700 (PDT) Message-ID: <4A78F3C6.4020602@joelhalpern.com> Date: Tue, 04 Aug 2009 22:51:50 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian E Carpenter References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> In-Reply-To: <4A78B51C.2010902@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 02:51:49 -0000 The problem is not what the ITRs and ETRs use the field for. They could / can use the field. The problem is that the UDP header was introduced specifically so that different flows would be different in a place that the routers would look when doing ECMP calculations. And the router to date do not use the flow label. Preliminary indications are that routers also won't use UDP-lite, because it is a different protocol, and they don't know it has port numbers. The simple path forward is to allow UDP with 0 checksum. If that is incorrect, then finding the correct path forward is going to be hard. Joel Brian E Carpenter wrote: > Hi Joel, > > > On 2009-08-05 03:08, Joel M. Halpern wrote: >> It has become clear with the passage of time that the description of the >> flow label in the original IPv6 specs served only to convince everyone >> not to use that field for anything. Even now, no one is sure what to do >> with it. > > If you're referring to the lame appendix to RFC2460, that's exactly > why we wrote RFC3697. My understanding is that some stacks do set the > flow label according to the SHOULD in RFC3697, but I'm not aware > of any deployed use cases (such as load balancing routers). The gap > is not in the basic specs but in exploitation. It's very similar to > what happened with the IPv4 TOS byte, and that took 20 years before > we (a) defined it properly and (b) began to see limited deployment, > as corporate VoIP took off. > > My expectation has always been that exploitation of the flow label > would stay on the back burner until IPv6 deployment reached a > significant level, because there isn't much benefit in optimising > flow handling for <1% of the traffic. So I don't really see anything > odd in the current situation. > > That said, I can't see any reason why ITRs and ETRs can't use > the flow label among themselves, in a way completely compatible > with RFC3697. But if their hardware engines can't include the > flow label in the n-tuple, that's a problem. > > Brian > From iljitsch@muada.com Wed Aug 5 04:44:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313493A683B; Wed, 5 Aug 2009 04:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYy2YSyCQi99; Wed, 5 Aug 2009 04:44:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id C24DD28C549; Wed, 5 Aug 2009 04:44:27 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n75Bi2I4050542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 13:44:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Vince Fuller In-Reply-To: <20090804232648.GA18233@vaf-lnx1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 13:44:19 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <20090804232648.GA18233@vaf-lnx1> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 11:44:50 -0000 On 5 aug 2009, at 1:26, Vince Fuller wrote: > Specifying some alternate reality and hoping that the operational > world will > modify its behavior to match Isn't that the business the IETF is in? > doesn't seem very practical, particularly since > one of LISP's virtues is that it requires no changes to the transit > routing > system. If we get router vendors on board with flow label ECMP for IPv6 now, by the time we have those multi-gigabit IPv6 flows between a single ITR/ETR pair, we'll be in reasonable shape. I would be very interested to hear what the status of ECMP for IPv6 is today, and especially if the implementations that can do this on the 5- tuple today are flexible enough to be able to look at the flow label without hardware changes. The problem with all of this in IPv6 is that there can be routing and fragmentation headers that make the port numbers appear in different places. When I tested this in 2005, the Cisco routers that I used wouldn't accommodate for this in their access lists, I so I can easily see IPv6 ECMP not looking at the 5-tuple but the 3-tuple, not be able to look at the 5-tuple consistently or simply not exist at all. From hartmans@mit.edu Wed Aug 5 05:59:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBC53A687B; Wed, 5 Aug 2009 05:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94iomPdvKLmy; Wed, 5 Aug 2009 05:59:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 9C2573A6C78; Wed, 5 Aug 2009 05:59:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4375351C3; Wed, 5 Aug 2009 08:59:33 -0400 (EDT) To: Margaret Wasserman References: <20090730233310.4A4EB6BE591@mercury.lcs.mit.edu> <83A588D4-6066-4148-A313-8344DE77CA0E@lilacglade.org> From: Sam Hartman Date: Wed, 05 Aug 2009 08:59:33 -0400 In-Reply-To: <83A588D4-6066-4148-A313-8344DE77CA0E@lilacglade.org> (Margaret Wasserman's message of "Tue\, 4 Aug 2009 21\:00\:05 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 12:59:36 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Hi Noel, Margaret> On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote: >> > Dino, why don't we just drop the 'inside IPv6' encapsulations from >> the spec? I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The >> IPv6 encapsulations could be documented in a short non-IETF >> note that's posted on a personal web page somewhere. (I'm >> assuming here that there are a few ISPs who'd actually want to >> run inside IPv6, otherwise we could just drop them entirely.) Margaret> To drop the encapsulation in IPv6, you'd need to get Margaret> LISP WG consensus to do so. for a variety of reasons , I'd like to stop this thread here. If you believe there is additional discussion of removing IPV6 encapsulation from the LISP spec that needs to happen on the LISP mailing list, please discuss with the chairs first. From hartmans@mit.edu Wed Aug 5 06:21:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08D93A6781 for ; Wed, 5 Aug 2009 06:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0sQ2Z-k771O for ; Wed, 5 Aug 2009 06:21:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D41D828C0E5 for ; Wed, 5 Aug 2009 06:21:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 77D2551C3; Wed, 5 Aug 2009 09:21:06 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Wed, 05 Aug 2009 09:21:06 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 13:21:05 -0000 Folks, as you have no doubt noticed, the issue of what the LISP spec should say about IPV6 UDP checksums has been raised in force. It's tied up in a lot of other issues. Lars has made it absolutely clear that when the process completes, we need to be consistent with the current IETF consensus at the time our documents are published. One of the jobs of the chairs will be to check the documents for that sort of consistency before forwarding to the IESG. Trying to convince the rest of the IETF to change their consensus and having the LISP specs reflect that consensus is definitely something we can do. You've seen a lot of discussion that includes both the 6man working group and the LISP working group lately as members of our community have tried to do that and others have asked questions or disagreed. It's clear from the traffic so far that the broader discussion--the one including 6man--is not over yet. so, we here in the LISP working group are faced with the question of what should the LISP spec say while that discussion is ongoing. I'd like to solicit opinions from this community about what goes in the current LISP spec. Hopefully, the narrow consensus within LISP is more clear so that we can focus on other things within this working group. Here are options as I see them: 1) We can use 0 checksums with UDP, adding a normative reference to a standards track document updating RFC 2460. Our spec will block behind this standards track document and will move no faster than it does. If the IETF chooses to go a different route, we will be faced with having to make incompatible changes to LISP late in the process. If that happens, individuals can come to the personal conclusion that they are no longer interested in spending effort on the IETF LISP spec, but they will not have the option of publishing a LISP spec through the IETF that disagrees with IETF consensus. 2) We can change LISP to use UDP-light. 3) We can make more significant changes to the LISP encapsulation. I want to stress that if we choose option 1, the only way we will be successful is if members of this community spend the necessary energy in 6man and the IETF at large to build an IETF-wide consensus behind the proposed change. No matter how strongly felt and unified feelings are in the LISP working group, that alone will not make an IETF consensus. Thanks for your input, Sam Hartman LISP Co-chair From mrw@lilacglade.org Wed Aug 5 07:16:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F443A6958 for ; Wed, 5 Aug 2009 07:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdvmBxRXQfdZ for ; Wed, 5 Aug 2009 07:16:40 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 806683A6D09 for ; Wed, 5 Aug 2009 07:16:40 -0700 (PDT) Received: from OMTA19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA01.westchester.pa.mail.comcast.net with comcast id QbDg1c00327AodY51eGkqh; Wed, 05 Aug 2009 14:16:44 +0000 Received: from lilac.sandstorm.net ([69.33.111.74]) by OMTA19.westchester.pa.mail.comcast.net with comcast id QeKF1c0041cMU3H3feKJLX; Wed, 05 Aug 2009 14:19:29 +0000 Message-Id: <28077E14-4F07-4CB4-8AA4-5F6EA9886063@lilacglade.org> From: Margaret Wasserman To: Joel M. Halpern In-Reply-To: <4A78F3C6.4020602@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 10:16:27 -0400 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 14:16:40 -0000 Hi Joel, On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > The problem is not what the ITRs and ETRs use the field for. They > could / can use the field. > The problem is that the UDP header was introduced specifically so > that different flows would be different in a place that the routers > would look when doing ECMP calculations. > And the router to date do not use the flow label. > Preliminary indications are that routers also won't use UDP-lite, > because it is a different protocol, and they don't know it has port > numbers. > > The simple path forward is to allow UDP with 0 checksum. > If that is incorrect, then finding the correct path forward is going > to be hard. We're talking about the ECMP calculations in _IPv6_ routers here, right? Do you really believe that enough IPv6 routers have shipped with this sort of ECMP behavior in _hardware_ that we need to consider that legacy deployment? I'm somewhat skeptical that this could be the case... If we're going to make design compromises to deal with currently-deployed hardware, I'd like to see some evidence that this hardware actually exists in numbers that are worth considering. Note, I'm not asking how many routers have been shipped that support IPv6, nor am I asking whether those routers support ECMP (in software). I'm not even asking whether some router vendors have taped out versions of silicon that are so inflexible that they will only support IPv6 ECMP using UDP ports (not the flow label or UDP-Lite)... What I am asking is whether IPv6 routers containing that silicon exist in real-world deployments in large enough numbers that they should be considered in our design choices. Thoughts? Margaret From shane@castlepoint.net Wed Aug 5 07:30:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FF33A657C; Wed, 5 Aug 2009 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omq2SsFUZs5p; Wed, 5 Aug 2009 07:30:06 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B7C8A28C4BF; Wed, 5 Aug 2009 07:29:28 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id A1F7F2684E1; Wed, 5 Aug 2009 08:29:31 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 05 Aug 2009 08:29:31 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=57044; data-bytes=0 Message-Id: <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> From: Shane Amante To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 08:29:31 -0600 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 14:30:07 -0000 Margaret, On Aug 5, 2009, at 08:12 MDT, Margaret Wasserman wrote: > Hi Joel, > > On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > >> The problem is not what the ITRs and ETRs use the field for. They >> could / can use the field. >> The problem is that the UDP header was introduced specifically so >> that different flows would be different in a place that the routers >> would look when doing ECMP calculations. >> And the router to date do not use the flow label. >> Preliminary indications are that routers also won't use UDP-lite, >> because it is a different protocol, and they don't know it has port >> numbers. >> >> The simple path forward is to allow UDP with 0 checksum. >> If that is incorrect, then finding the correct path forward is >> going to be hard. > > We're talking about the ECMP calculations in _IPv6_ routers here, > right? Do you really believe that enough IPv6 routers have shipped > with this sort of ECMP behavior in _hardware_ that we need to > consider that legacy deployment? I'm somewhat skeptical that this > could be the case... If we're going to make design compromises to > deal with currently-deployed hardware, I'd like to see some evidence > that this hardware actually exists in numbers that are worth > considering. > > Note, I'm not asking how many routers have been shipped that support > IPv6, nor am I asking whether those routers support ECMP (in > software). I'm not even asking whether some router vendors have > taped out versions of silicon that are so inflexible that they will > only support IPv6 ECMP using UDP ports (not the flow label or UDP- > Lite)... What I am asking is whether IPv6 routers containing that > silicon exist in real-world deployments in large enough numbers that > they should be considered in our design choices. Take a look at the following URL: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit (Note, I can't vouch for the accuracy of the entire list, but it's about the best publicly available list I've seen). That list includes some very large networks. -shane From byzek@cisco.com Wed Aug 5 08:00:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC22928C511; Wed, 5 Aug 2009 08:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8FOrub4jGsZ; Wed, 5 Aug 2009 08:00:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6F8C228C57D; Wed, 5 Aug 2009 08:00:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAE47eUqrR7O6/2dsb2JhbACKCpATohmIKZBaBYQYgVE X-IronPort-AV: E=Sophos;i="4.43,329,1246838400"; d="scan'208";a="223767563" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2009 15:00:28 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n75F0SJB005242; Wed, 5 Aug 2009 08:00:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n75F0RH2000767; Wed, 5 Aug 2009 15:00:28 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 08:00:27 -0700 Received: from 64.102.49.143 ([64.102.49.143]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Aug 2009 15:00:27 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 05 Aug 2009 10:59:46 -0400 From: byzek To: Margaret Wasserman Message-ID: Thread-Topic: [lisp] IPv6 UDP checksum issue Thread-Index: AcoV3V8LopmQLnR4nES6/nGQC5Cn6Q== In-Reply-To: <4EFCBD42-BCF0-4B60-9B50-6F355DD03534@lilacglade.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 05 Aug 2009 15:00:27.0737 (UTC) FILETIME=[77EBAC90:01CA15DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1823; t=1249484428; x=1250348428; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=byzek@cisco.com; z=From:=20byzek=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=FKLE0QUXsByDw/zVwboYMHcygCQG8eOVeVI8RSN0XMg=; b=yEy+nQxfAJD70RuQAIVzVTQyr1yXsxu4xBkPt65nUkHZghj0tYSYqU5w7u AgmRHLpTlwReor1YpihfRFe/VkS5Nh7U98hv0WoUNRUMm8211cihrlTgP+d7 WjDN7G5kQH; Authentication-Results: sj-dkim-2; header.From=byzek@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 15:00:37 -0000 Hi Margaret, On Tue 8/4/09 8:53 PM, "Margaret Wasserman" wrote: >=20 > Hi Byzek, >=20 > On Jul 30, 2009, at 8:31 PM, byzek wrote: >>=20 >> It's not about performance; a large percentage of the currently- >> deployed >> hardware can=B9t do UDP checksum calculations during encapsulation >> because it >> doesn=B9t have access to the entire packet. Most hardware is >> streamlined to >> only provide the first n bytes of a packet to the forwarding engine, >> where >> typically n < 128. >=20 > This is one of the primary reasons, as I understood it, why UDP-Lite > was defined the way it was -- to allow for a transport-layer checksum, > including an IP pseudo-header checksum, in IPv6, without the need to > traverse the entire packet. In the LISP case, all of the bytes that > would need to be "checksummed" for UDP-Lite would be bytes that were > _added to the packet_ by the LISP encapsulating router. >=20 > When an IPv4/UDP header is pre-pended by a LISP router, the lisp ETR > needs to calculate the IP header checksum over 20 bytes (the IP header). >=20 > If an IPv6/UDP-Lite header were pre-pended by a LISP router, the ETR > would need to calculate an IP header checksum over 48 bytes (the IP > pseudo-header and the UDP header). I think you mean xTR, correct? ITR does it on ingress, ETR does it on egress. As long as we don't have to go deeper in the packet than that, most hardwar= e that would be performing encap/decap is at least capable of doing this, yes= . -J >=20 > While I understand that 48 bytes is larger than 20 bytes, we aren't > really talking about a major difference when the checksum algorithm is > well-optimized and all of the pre-pended header bytes are already in > memory. >=20 > Margaret >=20 >=20 >=20 From hartmans@mit.edu Wed Aug 5 08:01:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F6528C3E1; Wed, 5 Aug 2009 08:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6OMCA8mAZhN; Wed, 5 Aug 2009 08:01:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 9ADFD28C4F2; Wed, 5 Aug 2009 08:01:15 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 252F364492; Wed, 5 Aug 2009 11:01:17 -0400 (EDT) To: Shane Amante References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> From: Sam Hartman Date: Wed, 05 Aug 2009 11:01:17 -0400 In-Reply-To: <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> (Shane Amante's message of "Wed\, 5 Aug 2009 08\:29\:31 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 15:01:16 -0000 >>>>> "Shane" == Shane Amante writes: Shane> Take a look at the following URL: Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Shane> (Note, I can't vouch for the accuracy of the entire list, Shane> but it's about the best publicly available list I've seen). Shane> That list includes some very large networks. Thanks for the data! Naturally that's only part of the answer to Margaret's question. We know which companies offer native IPV6 transit service. We don't know: 1) How much V6 traffic they have 2) Whether they have V6 infrastructure that would scale to their current V6 traffic or say their current V4 traffic 3) How much is done in hardware for their V6 infrastructure. 4) How much of their network supports V6/how widespread their V6 works. Any information you can provide on these sorts of questions would be very useful. From remi.despres@free.fr Tue Aug 4 10:57:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAE73A7075; Tue, 4 Aug 2009 10:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzA8hO77f+SO; Tue, 4 Aug 2009 10:57:15 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6E7F03A68D3; Tue, 4 Aug 2009 10:57:12 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 41E0AE0810A; Tue, 4 Aug 2009 19:57:10 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1D7E8E0814F; Tue, 4 Aug 2009 19:57:08 +0200 (CEST) In-Reply-To: <4A784EEF.2020405@joelhalpern.com> References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <65A14E2C-9662-44C5-B7F8-F71170B9FD53@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 19:57:07 +0200 To: Joel M. Halpern X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue - Flowlabel use already specified X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 17:57:16 -0000 Le 4 ao=FBt 09 =E0 17:08, Joel M. Halpern a =E9crit : > It has become clear with the passage of time that the description =20 > of the flow label in the original IPv6 specs served only to =20 > convince everyone not to use that field for anything. Even now, no =20= > one is sure what to do with it. RFC 3697, which is on standards track, specifies how to use flowlabels. I would personally have no objection to it's deprecation, but it's here. RD From mrw@sandstorm.net Tue Aug 4 12:01:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D963A6943; Tue, 4 Aug 2009 12:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xn4V-Rf8A5A; Tue, 4 Aug 2009 12:01:16 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CEEDB28C444; Tue, 4 Aug 2009 12:01:05 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74J12pR096212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:01:02 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <10223B44-6C4E-4A81-B5CE-86B4BE13B3A2@sandstorm.net> From: Margaret Wasserman To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 15:01:01 -0400 References: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:01:17 -0000 On Jul 31, 2009, at 3:06 AM, R=E9mi Denis-Courmont wrote: > > is basically UDP except the checksum would only covering the IPv6 and > transport header. Hmmph, this is just like UDP-Lite really but it =20 > seems > like there is opposition to overloading UDP-Lite. Then the 64-=20 > translators > would convert it to normal UDP/IPv4... ? Why do you think that this would be "overloading UDP-Lite"? And what =20= is the opposition? We used UDP-Lite in a very similar situation in CAPWAP for very =20 similar reasons. We needed to be able to checksum-protect the outer =20 headers in an IP-in-IPv6/UDP(-ish) encapsulation, and we did not want =20= the encapsulator to be required to (re-)checksum the entire payload. =20= IMO, that is a very sound reason to use UDP-Lite, and one that has =20 IETF precedent in at least one standards-track RFC. Margaret= From mrw@sandstorm.net Tue Aug 4 12:05:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08033A6971; Tue, 4 Aug 2009 12:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzMu-DUZ91Id; Tue, 4 Aug 2009 12:05:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 07A303A6A18; Tue, 4 Aug 2009 12:05:49 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74J5mW5096443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:05:48 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <61D62CD4-B6A5-469F-A88E-C79CA3D7C69D@sandstorm.net> From: Margaret Wasserman To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 15:05:47 -0400 References: X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:05:51 -0000 Hi Pekka, On Jul 31, 2009, at 3:47 AM, Pekka Savola wrote: > On Thu, 30 Jul 2009, byzek wrote: >> It's not about performance; a large percentage of the currently-=20 >> deployed >> hardware can=B9t do UDP checksum calculations during encapsulation =20= >> because it >> doesn=B9t have access to the entire packet. Most hardware is =20 >> streamlined to >> only provide the first n bytes of a packet to the forwarding =20 >> engine, where >> typically n < 128. > > I'm somewhat sympathetic to this concern, but I've been assured that =20= > it's possible to compute the outer checksum by doing an incremental =20= > checksum calculation (see e.g. RFC1624) using the inner packet's =20 > checksum. This would not require the access to the whole packet. =20 > This might work at least when encapsulating IPv4 over IPv6 UDP; I =20 > don't see how you could do this with IPv6 over IPv6 UDP due to the =20 > lack of "base" checksum. Any thoughts on how applicable this could =20= > be? You would not be able to incrementally calculate the outer UDP =20 checksum based on the inner IPv4 checksum, you would have to do it =20 based on the inner UDP or TCP checksum by subtracting the inner IP =20 pseudo-header checksum and adding the checksum for the outer IP pseudo-=20= header, the UDP header and the inner IP header (all bytes, because it =20= is being treated as UDP payload by the outer UDP header). You might =20 run into problems with this approach, though, if you needed to =20 encapsulate non-TCP/UDP packets and/or encapsulated IPv4 packets with =20= a zero UDP checksum. In those cases, you'd have to checksum the whole =20= packet. > > =46rom the point of view of AMT specification, I don't see the need =20= > for IPv6 UDP encapsulation, even if you buy the LAG argument (I'm =20 > not sure if I can see 10G+ of traffic being LISP encapsulated =20 > between a couple of routers), it doesn't apply to AMT due to =20 > different traffic patterns. My understanding is that AMT is using UDP so that they can use =20 different UDP ports for different AMT flows, similar to the LAG =20 argument for LISP. Margaret From mrw@sandstorm.net Tue Aug 4 12:39:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C4628C101; Tue, 4 Aug 2009 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irQilZeHe0yI; Tue, 4 Aug 2009 12:39:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id EEEF428C2F2; Tue, 4 Aug 2009 12:39:28 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74Jbxjo098021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:37:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <41CC608D-E261-4CD8-A22E-86FCFEE220FD@sandstorm.net> From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 15:37:58 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:39:46 -0000 On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote: > http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 > > We intend to rev this shortly and comments would be appreciated. If you do rev this document, I would like to see: (1) An explanation of the difference in applicability between this mechanism and UDP-Lite. (2) A specific applicability statement for when this mechanism can (and can't) be used. Would we be allowing this mechanism _only_ for cases where IP is tunneled inside UDP/IP? What about the AMT case? (3) A section listing considerations that must be documented for protocols that use this mechanism, including: (3a) What happens when the destination IP address is corrupted in transit? (Note: This isn't a concern in IPv4, as the IP header checksum will result in this packet being discarded by the receiving IP stack). (3a.i) What if a node that does not implement this protocol receives the packet? (3a.ii) What if a node that does implement this protocol receives a packet destined for another node? (3b) What happens when the source IP address is corrupted in transit? (Note: This isn't a concern in IPv4, as the IP header checksum will result in this packet being discarded by the receiving IP stack). (3b.i) What happens when a node that does not implement this protocol receives the ICMP "port unreachable" error? (3b.ii) What happens when a node that does implement this protocol receives an ICMP "port unreachable" error for a packet it didn't send? (3c) What happens if one or both of the UDP ports are corrupted in transit? (Note: This can happen in IPv4 in the zero checksum case, too, but not with UDP checksums turned on and/or UDP-Lite). (3d) What types of middleboxes does the protocol need to cross (routers, NAT boxes, firewalls, etc.), and how will those middleboxes deal with these packet I don't really have enough knowledge to answer these questions for LISP. I tried to go down this path in an earlier message, and Dino didn't understand what I was saying, but I'll try to do it once again. Please correct me if I am missing something. I am making the assumption that (unlike AMT), all LISP packets will be sent to a specific UDP port assigned to LISP. Also, I am making the assumption that if we write this document, some other protocols (besides LISP) will make use of it, so some IP stacks on non-LISP nodes will process these packets. (3a.i) If a node that doesn't implement LISP receives this packet, it may be passed up to UDP (if zero checksums are supported). At that point, though, it will be thrown away because there is no process listening on the LISP port and an ICMPv6 "port unreachable" error will be generated. (This is different than the IPv4 case, where the packet will never make it to UDP). (3a.ii) If a node that does implement LISP receives this packet, it will be sent to the LISP process, which will recognize that it is an encapsulated LISP packet. What then? (Note: Again, this wouldn't happen in IPv4, as the packet would be discarded by the receiving IP stack.). (3b.i) If a node that doesn't implement LISP receives an ICMP port unreachable for the LISP port, it may have a process that is using the local port from the original LISP packet. Will that process receive the destination unreachable? Or will the message be thrown away because the destination port doesn't match? I think this might depend on how the process was bound to its socket, or something. Can someone help me out here? (Note: This won't happen in IPv4, because the packet would have been discarded by IP, not by UDP). (3b.ii) If a node that does implement LISP receives an ICMP port unreachable, it still might not have a process that is using the corresponding source port (right?). In that case, I think that this is the same as 3b.i... Would another process receive this error? And, if so, how would it respond? (3c) If the ports were corrupted in transit, we might get packets delivered to the wrong process (on the right machine) and/or responses or errors sent to the wrong process (on the right machine). I think this all would have been covered by the above cases. (3d) I don't know how middleboxes will deal with this... What do IPv6 routers do today with zero-checksum UDP packets? What other IPv6 middleboxes exist today, and what would they do? Personally, I think this is something we would need to understand pretty fully before we could decide that turning off IPv6 UDP checksums is a superior choice to using IP-in-IPv6 encapsulation (no UDP), IP-in-IPv6/UDP-Lite encapsulation or UDP with checksums. These are also areas that we should explore in a general sense before we decide to publish Marshall's document as an alternative to using IP-in-IPv6 encapsulation, UDP-Lite, or UDP with checksums. Margaret From mrw@sandstorm.net Tue Aug 4 12:42:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9AE28C349; Tue, 4 Aug 2009 12:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdbmVNLyjRvs; Tue, 4 Aug 2009 12:42:35 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id BCD3D3A6FFC; Tue, 4 Aug 2009 12:42:34 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74JgDSb098283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:42:13 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <17BBDBA7-1535-4A3A-B82F-38C1BF0BA21E@sandstorm.net> From: Margaret Wasserman To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200908040015.43375.remi@remlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 15:42:12 -0400 References: <8C2160F1-2B13-40B9-AB71-398F7A48721C@sandstorm.net> <200908040015.43375.remi@remlab.net> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:42:35 -0000 On Aug 3, 2009, at 5:15 PM, R=E9mi Denis-Courmont wrote: >> >> (1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable >> choice for LISP encapsulation? When we looked into this for CAPWAP >> (another IP-in-UDP/IP tunneling case), we found that UDP-Lite would >> meet our needs for IPv6, so we did not need to specify the use of =20 >> zero >> UDP checksums. > > You would expect 64-translators to convert UDP-Lite/IPv6 into UDP-=20 > Lite/IPv4 > and back. Converting UDP-Lite/IPv6-with-8-bytes-coverage into UDP/=20 > IPv4- > without-checksum sounds hackish :( Are we actually expecting 64-translators to exist between LISP routers? In the more general sense, this is something you need to deal with, =20 because there are things out there that use UDP-Lite. I don't see the =20= transform you have suggested as any worse than just dropping the IP =20 header checksum when converting from IPv4 to IPv6 in cases where it is =20= not covered by a transport layer checksum. >> (2) IP-in-IPv6: Why do you need the UDP encapsulation at all in >> IPv6? In IPv4, you may need it for NAT traversal, but it is not =20 >> clear >> that NATs will work the same way in IPv6. Or are there other reasons >> why you need the UDP encapsulation? > (...) > > Same problem. 64-translators would translate IP-in-IPv6 to IPIP and =20= > vice > versa. IPIP does not go through NATs. So, now we're running encapsulation protocols behind an IPv4 NAT _and_ =20= a 64-translator? Ick. > > That's why I was trying to suggest defining a new UDP-Lite-like =20 > transport > protocol that would only be allowed over IPv6 and that 64-translator =20= > would > convert into checksum-less UDP/IPv4. Why is the current UDP-Lite protocol not okay for this? Margaret From mrw@sandstorm.net Tue Aug 4 12:44:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828C43A6774; Tue, 4 Aug 2009 12:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5dMnq1YrPDF; Tue, 4 Aug 2009 12:44:46 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CABA828C108; Tue, 4 Aug 2009 12:44:35 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n74JiEMa098400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 15:44:14 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 15:44:14 -0400 References: <33104ba34b03a973c8d9ca7d23fe1ad9@chewa.net> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Aug 2009 19:44:47 -0000 On Aug 4, 2009, at 7:28 AM, Iljitsch van Beijnum wrote: > On 31 jul 2009, at 9:06, R=E9mi Denis-Courmont wrote: > >> Sounds like this would require a third datagram protocol number, that >> is basically UDP except the checksum would only covering the IPv6 and >> transport header. Hmmph, this is just like UDP-Lite really but it =20 >> seems >> like there is opposition to overloading UDP-Lite. Then the 64-=20 >> translators >> would convert it to normal UDP/IPv4... ? > > UDP ultra-lite: no length, no checksum, just port numbers. This is sort of like the UDP-TT proposal, except for the part where =20 UDP-TT overloads the UDP next-header type, hard-codes the length to 8 =20= and includes a checksum of the IP and UDP headers (which is fixed =20 value per flow)... Margaret= From pekkas@netcore.fi Wed Aug 5 07:25:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0904328C5B9; Wed, 5 Aug 2009 07:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJvFqjBSaTyN; Wed, 5 Aug 2009 07:25:09 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 9668328C584; Wed, 5 Aug 2009 07:24:38 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n75EOCmk006412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2009 17:24:12 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n75EOCQC006408; Wed, 5 Aug 2009 17:24:12 +0300 Date: Wed, 5 Aug 2009 17:24:12 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman In-Reply-To: <28077E14-4F07-4CB4-8AA4-5F6EA9886063@lilacglade.org> Message-ID: References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <28077E14-4F07-4CB4-8AA4-5F6EA9886063@lilacglade.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at otso.netcore.fi X-Virus-Status: Clean X-Mailman-Approved-At: Wed, 05 Aug 2009 08:49:30 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 14:25:10 -0000 On Wed, 5 Aug 2009, Margaret Wasserman wrote: > Do you really believe that enough IPv6 routers have shipped with > this sort of ECMP behavior in _hardware_ that we need to consider > that legacy deployment? I'm somewhat skeptical that this could be > the case... If we're going to make design compromises to deal with > currently-deployed hardware, I'd like to see some evidence that this > hardware actually exists in numbers that are worth considering. FWIW, Juniper docs say the following. Not sure what else they could do in hardware or what are the caveats. ======================== By default, IP version 6 (IPv6) packets are automatically load-balanced based on the following Layer 3 and Layer 4 information: * Source IP address * Destination IP address * Protocol * Source port number * Destination port number * Incoming interface index * Traffic class http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-policy/policy-configuring-per-packet-load-balancing.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From shane@castlepoint.net Wed Aug 5 09:50:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1DA3A71A5; Wed, 5 Aug 2009 09:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnZ9HcmadyrI; Wed, 5 Aug 2009 09:50:30 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4D17C3A688D; Wed, 5 Aug 2009 09:50:30 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 4B0D72684EA; Wed, 5 Aug 2009 10:50:33 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 05 Aug 2009 10:50:33 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=58841; data-bytes=0 Message-Id: From: Shane Amante To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 10:50:32 -0600 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 16:50:33 -0000 Sam, On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote: >>>>>> "Shane" == Shane Amante writes: > > Shane> Take a look at the following URL: > Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit > Shane> (Note, I can't vouch for the accuracy of the entire list, > Shane> but it's about the best publicly available list I've seen). > > Shane> That list includes some very large networks. > > > Thanks for the data! Naturally that's only part of the answer to > Margaret's question. We know which companies offer native IPV6 > transit service. > We don't know: > > 1) How much V6 traffic they have 2) Whether they have V6 > infrastructure that would scale to their current V6 traffic or say > their current V4 traffic 3) How much is done in hardware for their V6 > infrastructure. 4) How much of their network supports V6/how > widespread their V6 works. Any information you can provide on these > sorts of questions would be very useful. I think question #1 is a little impractical, given that data is highly sensitive/confidential to each network. However, one likely can Google/Bing around and find public Exchange points with graphs that show current v6 traffic (as compared to v4 traffic). Of course, I would highlight that these are *public* exchange points, thus they will not show v6 traffic going through private peering connections as well as staying Intra-provider, (i.e.: customer-to-customer inside a single provider) -- see first sentence about sensitivity/ confidentiality. That said, there have been presentations at the last couple of IETF's (I forget if it was in 'behave' or 'v6ops' WG's, or both) surrounding Free Telecom's rollout of '6rd' that show their v6 traffic, which has some astounding growth and traffic rates. Regardless, one should consider the following graphs a absolute "floor" of v6 traffic and there is definitely more, in absolute terms, v6 traffic than is visible in these graphs. Here's one example from AMS-IX showing v6 traffic: http://www.ams-ix.net/technical/stats/sflow/?type=ipv6 And, here are graphs showing Total traffic load, (I believe this includes the v6 traffic in the graph above, but am not 100% certain on that point): http://www.ams-ix.net/technical/stats/ According to these graphs, v6 traffic is just a fraction of v4 traffic, but it is definitely growing and, FWIW, it's a lot more than Inter-AS multicast traffic as seen by other graphs at the AMS-IX Web site. :-/ With respect to #2, SP's have been mandating that they only buy v6- capable HW for the last /several years/ as part of the normal growth/ replacement cycle of network equipment. So, yes, this equipment should scale to support v6 traffic at the same, (or nearly the same), rates as v4 traffic today. #3: All v6 forwarding is done in HW for larger, "PE" or "P" class devices, which are the subject of this thread. #4: Depends on where the carrier is at in their deployment of v6. However, I would refer you back to question #2, which is even if it's not technically offered at a given location today, it is only a matter of time given that the HW is already deployed to do so (and, has been deployed for several years). To bring this back up a level, while it's /possible/ to encourage vendors to adopt the IPv6 flow-label as input-keys to their hash- calculations for LAG/ECMP, it takes [a lot] of time to see that materialize in the field. Practically, you're probably looking at somewhere between, at best, a 3 - 5 year window, before it will actually appear in live, production networks, given that it has to be prioritized for development at the vendor, tested, released in software, then re-tested by the SP and, finally, deployed. That's not an "easy" process that happens in the blink-of-an-eye. That's not to say that we (SP's) should not "encourage" vendors to do this, anyway, (we are/will) however if LISP (or other protocols like it that depend on tunneling) quickly gain traction, we need a way to deal with these traffic flows in our networks today, without telling customers: "turn off protocol , because we can't deliver your packets". Perhaps one way to satisfy the parties in this conversation would be something along the following lines: - LISP, and other protocols that wish to use tunneling, adopt UDP-lite (or UDP w/ 0 checksums) as a MUST for near-term deployment; - LISP, and other protocols that wish to use tunneling, adopt IP-in- IPv6 tunneling with a flow-label required in the outer IPv6 header as a "SHOULD" for medium- to long-term deployments. ... assuming vendors successfully adopt the IPv6 flow-label as input- keys in their hash calculations at some point in the future, we come back and deprecate the UDP/IPv6 tunnel method and elevate IP-in-IPv6 w/ flow-labels to a MUST. It likely wouldn't hurt to go back and "tighten up" RFC 3697, as well, in order that it offers more prescriptive behavior in several places, not least of which would be: 1) How to deal with regular IP-in-IPv6 encapsulation, (i.e.: likely by creating a flow-label based on a "hash" of the incoming, to-be- encapsulated L3 & L4 header fields), since the RFC only discusses IPsec tunneling; and, 2) Removing other "gems" (or clarifying them) like the second sentence in the following: ---cut here--- IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key. ---cut here--- ... specifically, if "router performance" is meant to imply the behavior of load-balancing on ECMP/LAG paths, then router performance *is* heavily dependent on the distribution of flow-label values ... I've said all I'm going to say on this thread ... -shane From christopher.morrow@gmail.com Wed Aug 5 10:35:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C7B3A7200; Wed, 5 Aug 2009 10:35:14 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZE6yMD2sE9G; Wed, 5 Aug 2009 10:35:13 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id B763328C5EB; Wed, 5 Aug 2009 10:34:23 -0700 (PDT) Received: by qyk41 with SMTP id 41so258573qyk.29 for ; Wed, 05 Aug 2009 10:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eYwciBxbEwZuhB35OcZJEP//5NS7C/V8qWxTeWWWS8Q=; b=uColTln5UxnWM0H034CZtNwaNRCZflJZIhJuyhMQ8XWxxzFCbSMieqFcxikPLe26x7 lKIHo55uJWPbETnrSoobl/ZCDvg+yisJrzLAER+/F3xx7uzpcNHzobCWo74nWEo7KoGa Gkvjx3YvyfyakkVnowpY/ERa5FLIYWQLSdgZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XnVLPfqhOGau1OKeoz2oLiOVKlw0Y9XpSlICdjbo0VREZW6f5xe17tHfiBJ/wwSc9u L3FvuCXCUs1xs5X57quGdOzIpRYtoxVs/kA4SMTRX/tW8FMwSHA9UufiEjpT9FXsFBQ8 GbYNW+KlzhOR2Fw4lAq442LY7FyIu/oO1sXDU= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.19.213 with SMTP id c21mr7361931qab.103.1249493664487; Wed, 05 Aug 2009 10:34:24 -0700 (PDT) In-Reply-To: References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> Date: Wed, 5 Aug 2009 13:34:24 -0400 X-Google-Sender-Auth: ed45391740ff4ad9 Message-ID: <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 17:35:14 -0000 On Wed, Aug 5, 2009 at 12:50 PM, Shane Amante wrote: > Sam, > > On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote: >>>>>>> >>>>>>> "Shane" =3D=3D Shane Amante writes: >> >> =A0 Shane> Take a look at the following URL: >> =A0 Shane> http://www.sixxs.net/faq/connectivity/?faq=3Dipv6transit >> =A0 Shane> (Note, I can't vouch for the accuracy of the entire list, >> =A0 Shane> but it's about the best publicly available list I've seen). >> >> =A0 Shane> That list includes some very large networks. >> >> >> Thanks for the data! =A0Naturally that's only part of the answer to >> Margaret's question. =A0We know which companies offer native IPV6 >> transit service. >> We don't know: >> >> 1) How much V6 traffic they have 2) Whether they have V6 >> infrastructure that would scale to their current V6 traffic or say >> their current V4 traffic 3) How much is done in hardware for their V6 >> infrastructure. =A04) How much of their network supports V6/how >> widespread their V6 works. =A0Any information you can provide on these >> sorts of questions would be very useful. > > I think question #1 is a little impractical, given that data is highly > sensitive/confidential to each network. =A0However, one likely can Google= /Bing > around and find public Exchange points with graphs that show current v6 > traffic (as compared to v4 traffic). =A0Of course, I would highlight that > these are *public* exchange points, thus they will not show v6 traffic go= ing > through private peering connections as well as staying Intra-provider, > (i.e.: customer-to-customer inside a single provider) -- see first senten= ce > about sensitivity/confidentiality. =A0That said, there have been presenta= tions > at the last couple of IETF's (I forget if it was in 'behave' or 'v6ops' > WG's, or both) surrounding Free Telecom's rollout of '6rd' that show thei= r > v6 traffic, which has some astounding growth and traffic rates. =A0Regard= less, > one should consider the following graphs a absolute "floor" of v6 traffic > and there is definitely more, in absolute terms, v6 traffic than is visib= le > in these graphs. > Here's one example from AMS-IX showing v6 traffic: > http://www.ams-ix.net/technical/stats/sflow/?type=3Dipv6 > And, here are graphs showing Total traffic load, (I believe this includes > the v6 traffic in the graph above, but am not 100% certain on that point)= : > http://www.ams-ix.net/technical/stats/ > According to these graphs, v6 traffic is just a fraction of v4 traffic, b= ut > it is definitely growing and, FWIW, it's a lot more than Inter-AS multica= st > traffic as seen by other graphs at the AMS-IX Web site. =A0:-/ > > With respect to #2, SP's have been mandating that they only buy v6-capabl= e > HW for the last /several years/ as part of the normal growth/replacement > cycle of network equipment. =A0So, yes, this equipment should scale to su= pport > v6 traffic at the same, (or nearly the same), rates as v4 traffic today. > > #3: All v6 forwarding is done in HW for larger, "PE" or "P" class devices= , > which are the subject of this thread. > > #4: Depends on where the carrier is at in their deployment of v6. =A0Howe= ver, > I would refer you back to question #2, which is even if it's not technica= lly > offered at a given location today, it is only a matter of time given that > the HW is already deployed to do so (and, has been deployed for several > years). > > > To bring this back up a level, while it's /possible/ to encourage vendors= to > adopt the IPv6 flow-label as input-keys to their hash-calculations for > LAG/ECMP, it takes [a lot] of time to see that materialize in the field. > =A0Practically, you're probably looking at somewhere between, at best, a = 3 =A0- > 5 year window, before it will actually appear in live, production network= s, s/networks/hardware-shipped-by-vendors/ You may see 2-3 year cycle on new asics for this feature to appear... given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before hardware is on the shelf to purchase. Look at jason schiller's presos at IETF/RAWS/RRG that show 5-7 year lifecycle of equipment in a network, so add some years before shipped and deployed hardware is in general coverage in a network. Call it 10+ before it's ubiquitous... > given that it has to be prioritized for development at the vendor, tested= , > released in software, then re-tested by the SP and, finally, deployed. and hopefully deployed in the hardware, since that's where this decision is made today (in v4 and v6 by 5-tuple). Software routers are dead in any large SP for an serious workload. (P or PE devices) > =A0That's not an "easy" process that happens in the blink-of-an-eye. =A0T= hat's > not to say that we (SP's) should not "encourage" vendors to do this, anyw= ay, > (we are/will) however if LISP (or other protocols like it that depend on > tunneling) quickly gain traction, we need a way to deal with these traffi= c > flows in our networks today, without telling customers: "turn off protoco= l > , because we can't deliver your packets". =A0Perhaps one way to sati= sfy > the parties in this conversation would be something along the following > lines: > - LISP, and other protocols that wish to use tunneling, adopt UDP-lite (o= r > UDP w/ 0 checksums) as a MUST for near-term deployment; > - LISP, and other protocols that wish to use tunneling, adopt IP-in-IPv6 > tunneling with a flow-label required in the outer IPv6 header as a "SHOUL= D" > for medium- to long-term deployments. > ... assuming vendors successfully adopt the IPv6 flow-label as input-keys= in > their hash calculations at some point in the future, we come back and > deprecate the UDP/IPv6 tunnel method and elevate IP-in-IPv6 w/ flow-label= s > to a MUST. > > It likely wouldn't hurt to go back and "tighten up" RFC 3697, as well, in > order that it offers more prescriptive behavior in several places, not le= ast > of which would be: > 1) =A0How to deal with regular IP-in-IPv6 encapsulation, (i.e.: likely by > creating a flow-label based on a "hash" of the incoming, to-be-encapsulat= ed > L3 & L4 header fields), since the RFC only discusses IPsec tunneling; and= , > 2) =A0Removing other "gems" (or clarifying them) like the second sentence= in > the following: > ---cut here--- > IPv6 nodes MUST NOT assume any mathematical or other properties of the Fl= ow > Label > values assigned by source nodes. =A0Router performance SHOULD NOT be depe= ndent > on the > distribution of the Flow Label values. Especially, the Flow Label bits al= one > make > poor material for a hash key. > ---cut here--- 'flow label bits alone make a poor material for a hash key'... isn't this the reverse of saying that we'll (operators) require vendors to use flow-label for hashing on ECMP/LAG? If so, then... I don't think flow-label's going to cut it. -chris > ... specifically, if "router performance" is meant to imply the behavior = of > load-balancing on ECMP/LAG paths, then router performance *is* heavily > dependent on the distribution of flow-label values ... > > I've said all I'm going to say on this thread ... > > -shane > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jmh@joelhalpern.com Wed Aug 5 10:42:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5966428C5E4; Wed, 5 Aug 2009 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgo0CvkOhKsB; Wed, 5 Aug 2009 10:42:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 235773A71F5; Wed, 5 Aug 2009 10:42:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 514AB430972; Wed, 5 Aug 2009 10:42:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AE5CB430951; Wed, 5 Aug 2009 10:42:16 -0700 (PDT) Message-ID: <4A79C478.9020001@joelhalpern.com> Date: Wed, 05 Aug 2009 13:42:16 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ipv6@ietf.org References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> In-Reply-To: <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 17:42:15 -0000 Reading this discussion, there seem to be a small number of practical choices. If the vendor hardware that is / will be handling IPv6 can handle the flow label as part of the ECMP / LAG calcualtion, than an I-D / direction to use the flow label seems sensible. (This is about what will be used, not what off-the-shelf parts might support in some other box.) While hardware upgrades take a long time, software upgrades are easier, particularly if it makes the operators traffic handling work better. Conversely, if the hardware we have to count on will not be able to handle flow labels for ECMP / LAG hash calculations, then it probably also won't be able to handle alternate protocols (like UDP-lite). As such, everything that needs ECMP / LAG handling will need to have TCP or UDP encapsulations, and given that many of those are protected, we will want to allow UDP with 0 checksum. Yours, Joel From hartmans@mit.edu Wed Aug 5 10:43:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C9F3A6768; Wed, 5 Aug 2009 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22z1a4u1axwB; Wed, 5 Aug 2009 10:43:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 54F3A28C5FB; Wed, 5 Aug 2009 10:43:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0239A64492; Wed, 5 Aug 2009 13:43:24 -0400 (EDT) To: Shane Amante References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> From: Sam Hartman Date: Wed, 05 Aug 2009 13:43:24 -0400 In-Reply-To: (Shane Amante's message of "Wed\, 5 Aug 2009 10\:50\:32 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 17:43:28 -0000 >>>>> "Shane" == Shane Amante writes: Shane> With respect to #2, SP's have been mandating that they only Shane> buy v6- capable HW for the last /several years/ as part of Shane> the normal growth/ replacement cycle of network equipment. Shane> So, yes, this equipment should scale to support v6 traffic Shane> at the same, (or nearly the same), rates as v4 traffic Shane> today. I don't see how this follows at all. I can sell you a box that supports V6 and that provides much lower performance for V6 than V4, but that still meets your requirement of supporting V6. You may be trying to tell me that SP's are unwilling to buy such boxes and explicitly want boxes where V6 and V4 performance is the same. If that is what you are saying, it is very interesting, but it goes far beyond simply saying that SPs are buying V6-supporting devices. From mrw@sandstorm.net Wed Aug 5 11:33:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F6F3A6906; Wed, 5 Aug 2009 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBfS74OsNDKo; Wed, 5 Aug 2009 11:33:21 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id D32343A6803; Wed, 5 Aug 2009 11:33:20 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n75IXBur059104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 14:33:11 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> From: Margaret Wasserman To: Shane Amante In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 14:33:11 -0400 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 18:33:22 -0000 Hi Shane, On Aug 5, 2009, at 12:50 PM, Shane Amante wrote: > > To bring this back up a level, while it's /possible/ to encourage > vendors to adopt the IPv6 flow-label as input-keys to their hash- > calculations for LAG/ECMP, it takes [a lot] of time to see that > materialize in the field. Practically, you're probably looking at > somewhere between, at best, a 3 - 5 year window, before it will > actually appear in live, production networks, given that it has to > be prioritized for development at the vendor, tested, released in > software, then re-tested by the SP and, finally, deployed. That's > not an "easy" process that happens in the blink-of-an-eye. That's > not to say that we (SP's) should not "encourage" vendors to do this, > anyway, (we are/will) however if LISP (or other protocols like it > that depend on tunneling) quickly gain traction, we need a way to > deal with these traffic flows in our networks today, without telling > customers: "turn off protocol , because we can't deliver your > packets". ECMP of LISP flows is an optimization that only matters when there is a large amount of LISP traffic, right? Do you think there is a reasonable chance that LISP would be widely-enough to deployed to require this optimization in less than 3-to-5 years? > Perhaps one way to satisfy the parties in this conversation would be > something along the following lines: > - LISP, and other protocols that wish to use tunneling, adopt UDP- > lite (or UDP w/ 0 checksums) as a MUST for near-term deployment; > - LISP, and other protocols that wish to use tunneling, adopt IP-in- > IPv6 tunneling with a flow-label required in the outer IPv6 header > as a "SHOULD" for medium- to long-term deployments. > ... assuming vendors successfully adopt the IPv6 flow-label as input- > keys in their hash calculations at some point in the future, we come > back and deprecate the UDP/IPv6 tunnel method and elevate IP-in-IPv6 > w/ flow-labels to a MUST. I would agree to this statement if one of two things were to happen: (1) we were to remove "(or UDP w/0 checksums) -- making UDP-Lite a MUST in the near term", or (2) we were to satisfy ourselves that using zero checksums will not represent an operational problem for LISP, or for other applications that need to co-habitate with LISP, and we were to add a normative dependency on a document (like Marshall's, with edits) that would allow the use of UDP w/0 checksums over IPv6 in some cases, with LISP being an example of a case where this was appropriate. Margaret From christopher.morrow@gmail.com Wed Aug 5 11:55:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C2A28C5F0; Wed, 5 Aug 2009 11:55:08 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWIJjfhtvDDN; Wed, 5 Aug 2009 11:55:07 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id CEC4728C636; Wed, 5 Aug 2009 11:54:20 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so127788qwi.31 for ; Wed, 05 Aug 2009 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sNqJxxhSj8ox/SWPl11OuH4KM/w8P7DfkPwSIbDQWqc=; b=up3lXJpamvjx34VMZnEsUyhnGMsykHCveHTGug2veY22FPpDdJQbXZvFgl3vg2vJI4 9F6EZXPcA8NvgMzHtRxX32RMpOyV2xH+IGR0K+vybnfVxb3owNsMazNZ6pJ/8iVQmKa4 NbkUDMWjAvJHnY/XbbfGdiD1X1OmuOWgAnnJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AcpK+FJUG0+fD4WObHFj9KoL5BRBQblcjB5Je7Vw+rC/WZK7eIWmWzm9y/Kdtvjfj7 GHClGMG4plFV2Ft/uQxrLGD7JrqUgPG4Uwajp9W0ojljHiJik9vKhekmYm3QNBNZp8i1 3LEYFn3KHhJqhQhcdDg7Yo2mWlfve1xgS9dCQ= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.61.9 with SMTP id r9mr7539208qah.84.1249498461776; Wed, 05 Aug 2009 11:54:21 -0700 (PDT) In-Reply-To: <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> References: <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> Date: Wed, 5 Aug 2009 14:54:21 -0400 X-Google-Sender-Auth: d48d93680c17524c Message-ID: <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> From: Christopher Morrow To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 18:55:08 -0000 On Wed, Aug 5, 2009 at 2:33 PM, Margaret Wasserman wrote= : > > Hi Shane, > > On Aug 5, 2009, at 12:50 PM, Shane Amante wrote: >> >> To bring this back up a level, while it's /possible/ to encourage vendor= s >> to adopt the IPv6 flow-label as input-keys to their hash-calculations fo= r >> LAG/ECMP, it takes [a lot] of time to see that materialize in the field. >> =A0Practically, you're probably looking at somewhere between, at best, a= 3 =A0- >> 5 year window, before it will actually appear in live, production networ= ks, >> given that it has to be prioritized for development at the vendor, teste= d, >> released in software, then re-tested by the SP and, finally, deployed. >> =A0That's not an "easy" process that happens in the blink-of-an-eye. =A0= That's >> not to say that we (SP's) should not "encourage" vendors to do this, any= way, >> (we are/will) however if LISP (or other protocols like it that depend on >> tunneling) quickly gain traction, we need a way to deal with these traff= ic >> flows in our networks today, without telling customers: "turn off protoc= ol >> , because we can't deliver your packets". > > ECMP of LISP flows is an optimization that only matters when there is a > large amount of LISP traffic, right? =A0Do you think there is a reasonabl= e > chance that LISP would be widely-enough to deployed to require this > optimization in less than 3-to-5 years? in the extreme it's only needed for +1g flows, but there are lots of places where this may be necessary across smaller links ecmp'd together... Planning for no ECMP is not a plan that's sensible. There must be a way to sensibly hash traffic across more than one path in a network (not just local ecmp on a single LAG or set of links, think about multple lsp's between 2 distant endpoints). >> Perhaps one way to satisfy the parties in this conversation would be >> something along the following lines: >> - LISP, and other protocols that wish to use tunneling, adopt UDP-lite (= or >> UDP w/ 0 checksums) as a MUST for near-term deployment; >> - LISP, and other protocols that wish to use tunneling, adopt IP-in-IPv6 >> tunneling with a flow-label required in the outer IPv6 header as a "SHOU= LD" >> for medium- to long-term deployments. >> ... assuming vendors successfully adopt the IPv6 flow-label as input-key= s >> in their hash calculations at some point in the future, we come back and >> deprecate the UDP/IPv6 tunnel method and elevate IP-in-IPv6 w/ flow-labe= ls >> to a MUST. > > I would agree to this statement if one of two things were to happen: =A0(= 1) we > were to remove "(or UDP w/0 checksums) -- making UDP-Lite a MUST in the n= ear What was the original reason for removing the ability to do zero checksums on udp in v6? Are we sure that that decision is still sensible/appropriate in today's internet/world? -Chris > term", or (2) we were to satisfy ourselves that using zero checksums will > not represent an operational problem for LISP, or for other applications > that need to co-habitate with LISP, and we were to add a normative > dependency on a document (like Marshall's, with edits) that would allow t= he > use of UDP w/0 checksums over IPv6 in some cases, with LISP being an exam= ple > of a case where this was appropriate. > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Wed Aug 5 12:08:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F843A721A; Wed, 5 Aug 2009 12:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FdvyEIVllqo; Wed, 5 Aug 2009 12:08:08 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 705943A6AD5; Wed, 5 Aug 2009 12:08:08 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n75J89MB060998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 15:08:09 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <7B439CB4-6340-4158-9AAB-62599BA43EC6@sandstorm.net> From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4A79C478.9020001@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 15:08:09 -0400 References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> <4A79C478.9020001@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 19:08:09 -0000 Hi Joel, On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote: > Reading this discussion, there seem to be a small number of > practical choices. > > If the vendor hardware that is / will be handling IPv6 can handle > the flow label as part of the ECMP / LAG calcualtion, than an I-D / > direction to use the flow label seems sensible. (This is about what > will be used, not what off-the-shelf parts might support in some > other box.) While hardware upgrades take a long time, software > upgrades are easier, particularly if it makes the operators traffic > handling work better. > > Conversely, if the hardware we have to count on will not be able to > handle flow labels for ECMP / LAG hash calculations, then it > probably also won't be able to handle alternate protocols (like UDP- > lite). As such, everything that needs ECMP / LAG handling will need > to have TCP or UDP encapsulations, and given that many of those are > protected, we will want to allow UDP with 0 checksum. Could you explain what you mean by "given that many of those are protected"? I have this uncomfortable feeling that many of us (including me) are missing important details of what is being discussed here, and that the answer (or at least the problem) might become clearer if we could pool our knowledge... For example, I really don't understand how LISP, as currently defined, gains any significant LAG/ECMP benefits by including a UDP header in the outer packet... I understand that you want to be able to load- balance flows, even though they've been encapsulated by LISP. And I understand that current load balancers can only do this based on a few fields: src/dest IP addresses (two RLOCs), the IP traffic class, the IP protocol field (UDP=17) and the src/dest UDP ports (xxxx and LISP=4341). I just don't see how this works very well with LISP, though... The two RLOCs are likely to be constant for all traffic between the same LISP routers, and ITR/ETR pair (right?). The protocol will always be UDP (as currently defined), and LISP doesn't do anything unusual with the traffic class. So, are we expecting all of the load balancing for LISP flows between a specific ITR/ETR pair to be based on the single UDP port that _isn't_ 4341? Wouldn't this end-up with a bi- directional flow being broken into two different flows for load balancing, resulting in asymmetric routing, because the load balancer wouldn't see the same two UDP ports in both directions? I guess I really need to read that ECMP draft again... Margaret From jmh@joelhalpern.com Wed Aug 5 12:20:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F95A28C65E; Wed, 5 Aug 2009 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zAP4p8CV1LY; Wed, 5 Aug 2009 12:20:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8374C28C586; Wed, 5 Aug 2009 12:18:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B470C430992; Wed, 5 Aug 2009 12:18:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6187043098B; Wed, 5 Aug 2009 12:18:48 -0700 (PDT) Message-ID: <4A79DB17.7050006@joelhalpern.com> Date: Wed, 05 Aug 2009 15:18:47 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Margaret Wasserman References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> <4A79C478.9020001@joelhalpern.com> <7B439CB4-6340-4158-9AAB-62599BA43EC6@sandstorm.net> In-Reply-To: <7B439CB4-6340-4158-9AAB-62599BA43EC6@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 19:20:08 -0000 The basic model is that ECMP works by hashing all the fields. Therefore, you need two related properties: 1) You need those fields to be stable across all the packets in a flow in one direction. (There is absolutely no need for the answer to be the same in the reverse direction, as there is no order preservation issue between the two direcitons. 2) You need to be able to produce (with high probability) different answers for different flows, so that the hash logic can spread the different flows across different paths / links. By varying the source port in the UDP header LISP allows the balancing logic to spread flows. (The exactly logic it chooses to use to pick the source port is a local matter. If there are enough different traffic sources, it can use the inner source address (EID). Or it can use the EID, and where available source and dest port numbers. As you implied, there is no RFC on this. That is because it is a local behavior. (different devices can do different things, and it still works.) The problem we have surfaced is that other systems actually do depend upon this behavior, and therefore it probably needs to be documented. It has been a very long time since I actually worked with this aspect of router (forwarding) logic. Joel Margaret Wasserman wrote: > > Hi Joel, > > On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote: > >> Reading this discussion, there seem to be a small number of practical >> choices. >> >> If the vendor hardware that is / will be handling IPv6 can handle the >> flow label as part of the ECMP / LAG calcualtion, than an I-D / >> direction to use the flow label seems sensible. (This is about what >> will be used, not what off-the-shelf parts might support in some other >> box.) While hardware upgrades take a long time, software upgrades are >> easier, particularly if it makes the operators traffic handling work >> better. >> >> Conversely, if the hardware we have to count on will not be able to >> handle flow labels for ECMP / LAG hash calculations, then it probably >> also won't be able to handle alternate protocols (like UDP-lite). As >> such, everything that needs ECMP / LAG handling will need to have TCP >> or UDP encapsulations, and given that many of those are protected, we >> will want to allow UDP with 0 checksum. > > Could you explain what you mean by "given that many of those are > protected"? > > I have this uncomfortable feeling that many of us (including me) are > missing important details of what is being discussed here, and that the > answer (or at least the problem) might become clearer if we could pool > our knowledge... > > For example, I really don't understand how LISP, as currently defined, > gains any significant LAG/ECMP benefits by including a UDP header in the > outer packet... I understand that you want to be able to load-balance > flows, even though they've been encapsulated by LISP. And I understand > that current load balancers can only do this based on a few fields: > src/dest IP addresses (two RLOCs), the IP traffic class, the IP protocol > field (UDP=17) and the src/dest UDP ports (xxxx and LISP=4341). > > I just don't see how this works very well with LISP, though... The two > RLOCs are likely to be constant for all traffic between the same LISP > routers, and ITR/ETR pair (right?). The protocol will always be UDP (as > currently defined), and LISP doesn't do anything unusual with the > traffic class. So, are we expecting all of the load balancing for LISP > flows between a specific ITR/ETR pair to be based on the single UDP port > that _isn't_ 4341? Wouldn't this end-up with a bi-directional flow > being broken into two different flows for load balancing, resulting in > asymmetric routing, because the load balancer wouldn't see the same two > UDP ports in both directions? > > I guess I really need to read that ECMP draft again... > > Margaret > > > > > From mrw@sandstorm.net Wed Aug 5 12:32:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9167A3A6AD1; Wed, 5 Aug 2009 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQi9KQNz3Jdt; Wed, 5 Aug 2009 12:32:43 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AD3443A6933; Wed, 5 Aug 2009 12:32:43 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n75JWPVa062181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 15:32:25 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> From: Margaret Wasserman To: Christopher Morrow In-Reply-To: <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 15:32:25 -0400 References: <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 19:32:44 -0000 On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote: > > What was the original reason for removing the ability to do zero > checksums on udp in v6? Are we sure that that decision is still > sensible/appropriate in today's internet/world? I have not been around long enough to have been there when that decision was made. However, it has been revisited several times, so I've heard the re-hashed reasons... The removal of the IPv6 header checksum was done so that routers would not have to updated it on a hop-by-hop basis when they changed the IP TTL. Also, the IP header checksum calculation was seen as redundant for most traffic (TCP and UDP with checksums enabled), and people wanted to avoid the extra processing. However, there was concern that the removal of the IP header checksum in IPv6 would lessen the protection of the source/destination IP addresses and result in a significant (a multiplier of ~32,000) increase in the number of times that a UDP packet was accidentally delivered to the wrong destination address and/or apparently sourced from the wrong source address when UDP checksums were set to zero -- at the time there were vendors who shipped their IP stacks with UDP checksums turned off by default. There was concern that this would result in misdelivery of data to UDP applications (dropped connections or even corrupted data -- we all saw this when NFS data was corrupted on the wire), in replies sent to nodes that didn't send a request (perhaps interrupting valid exchanges), and/or in ICMP errors sent to nodes that didn't send the packet that generated the error (perhaps resulting in dropped communications or unintelligible user errors). The solution for this concern was to mandate UDP checksums for IPv6, so that the IP source and destination addresses would be protected by the UDP pseudo-header checksum. There might be other solutions that we could implement in LISP that would eliminate these concerns, as well. Margaret From christopher.morrow@gmail.com Wed Aug 5 12:55:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B185128C5B9; Wed, 5 Aug 2009 12:55:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ6-crepF8-F; Wed, 5 Aug 2009 12:55:08 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 4438D28C61A; Wed, 5 Aug 2009 12:55:01 -0700 (PDT) Received: by qyk41 with SMTP id 41so364662qyk.29 for ; Wed, 05 Aug 2009 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ICtftxQ7ATfJRNYm2OkY2fo4Fj8Vr4NedLkWgZjHurY=; b=EThXXPgVd2jK6d95oXqVEN/ayIgOP9fXICkOaK5mpuIIzkP+hpb/GbiWUG8Pzcz8X8 iYOaTpzeUJPBUqcLBTSjN32M8JbLnw6Rr0UxrgyLl5SMzIP60ItmbCmHUgskDKyUeR66 1mtBKRkLuLkbjVI3Q0CeczmJBEo5L9sSg+GtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Qrduqm9le2PrjQ5W9OWRENu/H7mqEwbkXjU1p5zbuFA6idD00OO5Jn/wQwW1L6OLA9 1g15ZhHGkojVFmiMrBGdJYYUUOGa3vVElBl0YndMCEl6X1abCMOndp4ZuwXWSRrJDXOY mZqAQ2U71oix5J0hIPZGzVP+7zr8J+lW1RVfo= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.61.9 with SMTP id r9mr7621010qah.84.1249502101636; Wed, 05 Aug 2009 12:55:01 -0700 (PDT) In-Reply-To: <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> References: <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> Date: Wed, 5 Aug 2009 15:55:01 -0400 X-Google-Sender-Auth: 2bbb7fe36f25c887 Message-ID: <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> From: Christopher Morrow To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 19:55:09 -0000 On Wed, Aug 5, 2009 at 3:32 PM, Margaret Wasserman wrote= : > > On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote: >> >> What was the original reason for removing the ability to do zero >> checksums on udp in v6? Are we sure that that decision is still >> sensible/appropriate in today's internet/world? > > I have not been around long enough to have been there when that decision = was > made. However, it has been revisited several times, so I've heard the > re-hashed reasons... > > The removal of the IPv6 header checksum was done so that routers would no= t > have to updated it on a hop-by-hop basis when they changed the IP TTL. > =A0Also, the IP header checksum calculation was seen as redundant for mos= t > traffic (TCP and UDP with checksums enabled), and people wanted to avoid = the > extra processing. The 'extra processing' is done today in v4 though, right? and apparently not a huge problem for routers even at line-rate 10/40G? > However, there was concern that the removal of the IP header checksum in > IPv6 would lessen the protection of the source/destination IP addresses a= nd > result in a significant (a multiplier of ~32,000) increase in the number = of > times that a UDP packet was accidentally delivered to the wrong destinati= on > address and/or apparently sourced from the wrong source address when UDP > checksums were set to zero -- at the time there were vendors who shipped > their IP stacks with UDP checksums turned off by default. =A0There was co= ncern > that this would result in misdelivery of data to UDP applications (droppe= d Does this happen today with any appreciable frequency? (on packets without udp checksum, say that come from edonkey/emule or other sources of zero/no checksum on udp) > connections or even corrupted data -- we all saw this when NFS data was > corrupted on the wire), in replies sent to nodes that didn't send a reque= st > (perhaps interrupting valid exchanges), and/or in ICMP errors sent to nod= es > that didn't send the packet that generated the error (perhaps resulting i= n > dropped communications or unintelligible user errors). This I don't recall at all... I think part of my question is we (as a group) are assuming that the reasons for requiring ipv6 udp checksums as stated +10 years ago are still valid, I don't see data supporting that fact. -Chris > The solution for this concern was to mandate UDP checksums for IPv6, so t= hat > the IP source and destination addresses would be protected by the UDP > pseudo-header checksum. > > There might be other solutions that we could implement in LISP that would > eliminate these concerns, as well. From mrw@sandstorm.net Wed Aug 5 14:07:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F77B3A722E; Wed, 5 Aug 2009 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjt7BXu0eaLi; Wed, 5 Aug 2009 14:07:47 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C91FA3A7221; Wed, 5 Aug 2009 14:07:46 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n75L7fne066700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 17:07:45 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Christopher Morrow In-Reply-To: <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 17:07:41 -0400 References: <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 21:07:47 -0000 On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote: >> > > This I don't recall at all... I think part of my question is we (as a > group) are assuming that the reasons for requiring ipv6 udp checksums > as stated +10 years ago are still valid, I don't see data supporting > that fact. There are some classic papers on this topic. The most recent I could find is from 2000: http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm In a quick re-read of this paper, I didn't see anything that is obviously dated about it. So, I'd assume its error rates and analysis are still pertinent, unless there is a more recent study that says otherwise. Margaret From christopher.morrow@gmail.com Wed Aug 5 11:06:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3AA28C5FD; Wed, 5 Aug 2009 11:06:51 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTIhJ7B9pgLk; Wed, 5 Aug 2009 11:06:50 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 9452428C4B7; Wed, 5 Aug 2009 11:06:50 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so113304qwi.31 for ; Wed, 05 Aug 2009 11:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l1w4e/0BSDROb4RXN3SJwKLrw/EmgDZ58v2KsMpphR0=; b=A7JuUJqzUv8MPp7SbJiLY4DfwbNqS3msprq9UaSgjZ36BshRWKUcBm1Ku4P05GolKg 70/Jrl3kua6ynMDro07sUbxrgViIJTQmzAZcFmMOlrNFZp7ayhExxBu5Ti1K45YBTkNl xUm9OnHuRHmNDxPXvwQQcyd9y1Q1Mrpw8KXfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wt77RmEuIsG34ewUREnHP7s1ltKHpJz6tr54i0Siwvo1T/2MPnnsAVJLnZwWHOwNag fe8aw0HXFGSC8gWteYbR4cua2Xe1+71PfXfJPznzUYLFN0IagMNvr/9+xUcp0QlyzuUM Dcf142YoWN5v0WJUP3TERm7nB81Nl2cMlc+YU= MIME-Version: 1.0 Received: by 10.224.67.129 with SMTP id r1mr7407540qai.246.1249495610667; Wed, 05 Aug 2009 11:06:50 -0700 (PDT) In-Reply-To: References: <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> Date: Wed, 5 Aug 2009 14:06:50 -0400 Message-ID: <75cb24520908051106j150d60b1j31452cf968a11bca@mail.gmail.com> From: Christopher Morrow To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 05 Aug 2009 16:02:05 -0700 Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 18:06:51 -0000 On Wed, Aug 5, 2009 at 1:43 PM, Sam Hartman wrote: >>>>>> "Shane" =3D=3D Shane Amante writes: > =A0 =A0Shane> With respect to #2, SP's have been mandating that they only > =A0 =A0Shane> buy v6- capable HW for the last /several years/ as part of > =A0 =A0Shane> the normal growth/ replacement cycle of network equipment. > =A0 =A0Shane> So, yes, this equipment should scale to support v6 traffic > =A0 =A0Shane> at the same, (or nearly the same), rates as v4 traffic > =A0 =A0Shane> today. > > I don't see how this follows at all. =A0I can sell you a box that > supports V6 and that provides much lower performance for V6 than V4, > but that still meets your requirement of supporting V6. > > You may be trying to tell me that SP's are unwilling to buy such boxes > and explicitly want boxes where V6 and V4 performance is the same. =A0If an SP can't know a-priori what protocol traffic is using on a transit device (presuming it supports both popular protocols of course). So, the only viable answer for an SP today who has dual-stacked their network is to demand performance parity. (which I think all large sp's are doing, which is one of the reasons that large SP deployments of v6 aren't moving along at a pace that some folks want. There are still significant numbers of devices not capable of doing line-rate v6 forwarding.) -chris > that is what you are saying, it is very interesting, but it goes far > beyond simply saying that SPs are buying V6-supporting devices. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From hesham@elevatemobile.com Wed Aug 5 15:10:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0E028C5AF; Wed, 5 Aug 2009 15:10:49 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPmpn+gZU717; Wed, 5 Aug 2009 15:10:48 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 95C6828C4FD; Wed, 5 Aug 2009 15:10:47 -0700 (PDT) Received: from [93.139.12.128] (helo=[192.168.1.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MYoh3-0000Za-8K; Thu, 06 Aug 2009 08:10:46 +1000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 06 Aug 2009 08:10:30 +1000 From: Hesham Soliman To: Brian E Carpenter , "Joel M. Halpern" Message-ID: Thread-Topic: Flow label redux [Re: [lisp] IPv6 UDP checksum issue] Thread-Index: AcoWGYtEhSq/kGY3LU+X/CTX5JOiTQ== In-Reply-To: <4A78B51C.2010902@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com X-Mailman-Approved-At: Wed, 05 Aug 2009 16:02:05 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Aug 2009 22:10:49 -0000 On 5/08/09 8:24 AM, "Brian E Carpenter" wrote: > Hi Joel, > > > On 2009-08-05 03:08, Joel M. Halpern wrote: >> It has become clear with the passage of time that the description of the >> flow label in the original IPv6 specs served only to convince everyone >> not to use that field for anything. Even now, no one is sure what to do >> with it. > > If you're referring to the lame appendix to RFC2460, that's exactly > why we wrote RFC3697. My understanding is that some stacks do set the > flow label according to the SHOULD in RFC3697, but I'm not aware > of any deployed use cases (such as load balancing routers). => One deployment case can be found in: draft-ietf-mext-flow-binding And the accompanying filter description draft-tsirtsis-mext-binary-filters Hesham The gap > is not in the basic specs but in exploitation. It's very similar to > what happened with the IPv4 TOS byte, and that took 20 years before > we (a) defined it properly and (b) began to see limited deployment, > as corporate VoIP took off. > > My expectation has always been that exploitation of the flow label > would stay on the back burner until IPv6 deployment reached a > significant level, because there isn't much benefit in optimising > flow handling for <1% of the traffic. So I don't really see anything > odd in the current situation. > > That said, I can't see any reason why ITRs and ETRs can't use > the flow label among themselves, in a way completely compatible > with RFC3697. But if their hardware engines can't include the > flow label in the n-tuple, that's a problem. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Wed Aug 5 21:20:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862CD3A6930; Wed, 5 Aug 2009 21:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNmM4fxLzJu2; Wed, 5 Aug 2009 21:20:10 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id 961583A6C40; Wed, 5 Aug 2009 21:20:09 -0700 (PDT) Received: by pzk8 with SMTP id 8so555271pzk.31 for ; Wed, 05 Aug 2009 21:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VlnaV/94Ws73g0VuXga3q+ncbA62rsa8iOXaEmx94SI=; b=rB/yFgZpeY/jF5XSjJPnwnUeybe7ER0TeZk9fBsyUfEhMye8stTHBXnCfTD1epEzGp gtqJ2s2j6pEqFxgbBT8jFBBQSN7913iTejmDyWvPsyWvVBSVMb5HR1PlqBVf0XqgJ+Fq qbNDUNEt8J7Hr8NmO5cgfmnSHz5nP7BmQpX5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pBLjtm16uuUJwqgO0hBVxFYCFuL3El415BlC8aYGkbbASV7FHgwQGbpjoVr3ktAhqo MgknwoOcm4g+E2BtwzQkEhC6XYp+8FINMy5nWN2XjgPoBB3g5eFKGih882dti3VR0Xfi O/1Xe9CvbrblJlTaB1B5OKwnDC3GxK5JgYB9M= Received: by 10.115.15.7 with SMTP id s7mr12799103wai.206.1249532410914; Wed, 05 Aug 2009 21:20:10 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id m6sm8038wag.68.2009.08.05.21.20.08 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 21:20:10 -0700 (PDT) Message-ID: <4A7A59E9.9070900@gmail.com> Date: Thu, 06 Aug 2009 16:19:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christopher Morrow References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> In-Reply-To: <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: [lisp] Flow label collision [Flow label redux [Re: IPv6 UDP checksum issue]] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 04:20:11 -0000 On 2009-08-06 05:34, Christopher Morrow wrote: ... >> 2) Removing other "gems" (or clarifying them) like the second sentence in >> the following: >> ---cut here--- >> IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow >> Label >> values assigned by source nodes. Router performance SHOULD NOT be dependent >> on the >> distribution of the Flow Label values. Especially, the Flow Label bits alone >> make >> poor material for a hash key. >> ---cut here--- > > 'flow label bits alone make a poor material for a hash key'... isn't > this the reverse of saying that we'll (operators) require vendors to > use flow-label for hashing on ECMP/LAG? If so, then... I don't think > flow-label's going to cut it. Please note the word "alone" in the above extract from RFC3697. That RFC specifically does not forbid flows from different sources that happen to go through the same router having the same flow label. That would have required some massive unscaleable flow-label-distribution protocol. (MPLS avoids this problem by having the downstream switch tell the upstream switch what label to use.) So even if the flow labels are pseudo-random, it's essential to include other material such as the addresses in the hash. But clearly a pseudo-random flow label will always improve the distribution of the resulting hash. Just don't use it *alone*. Our hidden fear when drafting those words was that lazy implementors would allocate flow labels starting at 1 and counting up. That would guarantee collisions in flow label space, strengthening the "poorness" of the material. And it would also mess up any router whose performance relied on the absence of flow label collisions. I hope this clarifies, as requested. There's no reason to remove these words, since they're true. The WG consensus at the time was to trim RFC3697 down to the normative text, so a lot of rationale was removed. Brian From pekkas@netcore.fi Wed Aug 5 22:03:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E2D3A6963; Wed, 5 Aug 2009 22:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYECU0i90fNd; Wed, 5 Aug 2009 22:03:22 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 57A013A691B; Wed, 5 Aug 2009 22:03:22 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n7653HWE022806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Aug 2009 08:03:17 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n7653FbC022803; Thu, 6 Aug 2009 08:03:15 +0300 Date: Thu, 6 Aug 2009 08:03:15 +0300 (EEST) From: Pekka Savola To: Christopher Morrow In-Reply-To: <4A7A59E9.9070900@gmail.com> Message-ID: References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> <4A7A59E9.9070900@gmail.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at otso.netcore.fi X-Virus-Status: Clean Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label collision [Flow label redux [Re: IPv6 UDP checksum issue]] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 05:03:23 -0000 On Thu, 6 Aug 2009, Brian E Carpenter wrote: >> 'flow label bits alone make a poor material for a hash key'... isn't >> this the reverse of saying that we'll (operators) require vendors to >> use flow-label for hashing on ECMP/LAG? If so, then... I don't think >> flow-label's going to cut it. > > Please note the word "alone" in the above extract from RFC3697. [...] And from the POV of LISP, this is not relevant. In IPv6, the hash key should probably consist of four-tuple {srcIP, dstIP, traffic class, flow label}. As such, the addition of flow label would make a great addition to the total hash key for the purposes of this discussion. Even though the flow label is set to zero, hashing would still work just fine but on IP/tclass granularity. By adding flow label, you could get finer granularity for flows that do set it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From shane@castlepoint.net Thu Aug 6 06:40:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E373A68FD; Thu, 6 Aug 2009 06:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLza+NGiJ-QG; Thu, 6 Aug 2009 06:40:26 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 090F03A68F4; Thu, 6 Aug 2009 06:40:26 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0419E2684EA; Thu, 6 Aug 2009 07:40:29 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 06 Aug 2009 07:40:28 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=49686; data-bytes=0 Message-Id: <5DA47DB3-0925-4F83-A1C2-E998B3735334@castlepoint.net> From: Shane Amante To: Brian E Carpenter In-Reply-To: <4A7A59E9.9070900@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 07:40:28 -0600 References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> <4A7A59E9.9070900@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label collision [Flow label redux [Re: IPv6 UDP checksum issue]] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 13:40:27 -0000 Brian, On Aug 5, 2009, at 22:19 MDT, Brian E Carpenter wrote: > On 2009-08-06 05:34, Christopher Morrow wrote: > ... >>> 2) Removing other "gems" (or clarifying them) like the second >>> sentence in >>> the following: >>> ---cut here--- >>> IPv6 nodes MUST NOT assume any mathematical or other properties of >>> the Flow >>> Label >>> values assigned by source nodes. Router performance SHOULD NOT be >>> dependent >>> on the >>> distribution of the Flow Label values. Especially, the Flow Label >>> bits alone >>> make >>> poor material for a hash key. >>> ---cut here--- >> >> 'flow label bits alone make a poor material for a hash key'... isn't >> this the reverse of saying that we'll (operators) require vendors to >> use flow-label for hashing on ECMP/LAG? If so, then... I don't think >> flow-label's going to cut it. > > Please note the word "alone" in the above extract from RFC3697. I think Chris may have read that a little too fast. :-) I wasn't concerned with the third sentence in the RFC, that makes sense and is clear. However, my concern was pertaining to the 2nd sentence, specifically: "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values". Specifically, if Flow Label values ARE used as one of the input-keys (in addition to src/dst IPv6 addresses), then the "distribution" of Flow Label values matters /a lot/ in order to achieve "good" load-balancing over LAG/ECMP paths and, consequently, good router performance. However, perhaps I'm misreading/misunderstanding that 2nd sentence. Can you clarify it's intent? -shane From mrw@sandstorm.net Thu Aug 6 07:11:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB0728C12B; Thu, 6 Aug 2009 07:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtBIvl+oSRgV; Thu, 6 Aug 2009 07:11:28 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3ACDC28C124; Thu, 6 Aug 2009 07:11:28 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n76EBEV5008181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2009 10:11:15 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: "Joel M. Halpern" In-Reply-To: <4A78F3C6.4020602@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 10:11:14 -0400 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 14:11:29 -0000 Hi Joel, I think I understand both sides of the UDP checksum issue now... We (or at least some of us) believe that it is a hard requirement to support ECMP through legacy routing equipment. This equipment will only identify flows using the 5-tuple described in the draft. These devices do not know about UDP-Lite, and they couldn't usefully load balance LISP traffic that was tunneled IP-in-IP, because there would be no source port to use as a hash value for identification of the original flow. We (or at least some of us) are concerned about using UDP zero checksums in IPv6, because of possible problems caused by corruption of the source/destination IP addresses or the next header field. These fields are protected in IPv4, even when UDP checksums are disabled. I have an idea that might work to satisfy both sets of concerns... What about putting a checksum field in the LISP header? We could checksum across the IP pseudo-header (at least for IPv6), and the LISP header. LISP nodes that receive these packets could check the checksum and discard packets that have been corrupted. In addition to resolving the concerns about corruption in the IPv6 header fields, this checksum would protect the LISP header, which contains some one- bit fields and a nonce that would be sensitive to corruption. We could also specify that LISP nodes that receive an ICMP error should check this checksum in the returned packet before acting on the error. We would still have to make sure that we understand the impacts of non- LISP nodes receiving corrupted LISP packets (which will probably be that the packet is dropped, which is fine), but we wouldn't have to worry about what happens when a LISP packet arrives at the wrong LISP node and/or when a response is sent back to the wrong LISP node. Thoughts? Margaret On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > The problem is not what the ITRs and ETRs use the field for. They > could / can use the field. > The problem is that the UDP header was introduced specifically so > that different flows would be different in a place that the routers > would look when doing ECMP calculations. > And the router to date do not use the flow label. > Preliminary indications are that routers also won't use UDP-lite, > because it is a different protocol, and they don't know it has port > numbers. > > The simple path forward is to allow UDP with 0 checksum. > If that is incorrect, then finding the correct path forward is going > to be hard. > > Joel > > Brian E Carpenter wrote: >> Hi Joel, >> On 2009-08-05 03:08, Joel M. Halpern wrote: >>> It has become clear with the passage of time that the description >>> of the >>> flow label in the original IPv6 specs served only to convince >>> everyone >>> not to use that field for anything. Even now, no one is sure what >>> to do >>> with it. >> If you're referring to the lame appendix to RFC2460, that's exactly >> why we wrote RFC3697. My understanding is that some stacks do set the >> flow label according to the SHOULD in RFC3697, but I'm not aware >> of any deployed use cases (such as load balancing routers). The gap >> is not in the basic specs but in exploitation. It's very similar to >> what happened with the IPv4 TOS byte, and that took 20 years before >> we (a) defined it properly and (b) began to see limited deployment, >> as corporate VoIP took off. >> My expectation has always been that exploitation of the flow label >> would stay on the back burner until IPv6 deployment reached a >> significant level, because there isn't much benefit in optimising >> flow handling for <1% of the traffic. So I don't really see anything >> odd in the current situation. >> That said, I can't see any reason why ITRs and ETRs can't use >> the flow label among themselves, in a way completely compatible >> with RFC3697. But if their hardware engines can't include the >> flow label in the n-tuple, that's a problem. >> Brian > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Thu Aug 6 07:22:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96A03A6AC5; Thu, 6 Aug 2009 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YTj-uRB6WBc; Thu, 6 Aug 2009 07:22:44 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 252753A698E; Thu, 6 Aug 2009 07:22:42 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 13D507064D70; Thu, 6 Aug 2009 16:22:43 +0200 (CEST) Message-Id: From: Luigi Iannone To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 16:22:42 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 14:22:45 -0000 On Aug 6, 2009, at 16:11 , Margaret Wasserman wrote: > > Hi Joel, > > I think I understand both sides of the UDP checksum issue now... > > We (or at least some of us) believe that it is a hard requirement to > support ECMP through legacy routing equipment. This equipment will > only identify flows using the 5-tuple described in the draft. These > devices do not know about UDP-Lite, and they couldn't usefully load > balance LISP traffic that was tunneled IP-in-IP, because there would > be no source port to use as a hash value for identification of the > original flow. > > We (or at least some of us) are concerned about using UDP zero > checksums in IPv6, because of possible problems caused by corruption > of the source/destination IP addresses or the next header field. > These fields are protected in IPv4, even when UDP checksums are > disabled. > > I have an idea that might work to satisfy both sets of concerns... > > What about putting a checksum field in the LISP header? We could > checksum across the IP pseudo-header (at least for IPv6), and the > LISP header. LISP nodes that receive these packets could check the > checksum and discard packets that have been corrupted. In addition > to resolving the concerns about corruption in the IPv6 header > fields, this checksum would protect the LISP header, which contains > some one-bit fields and a nonce that would be sensitive to > corruption. We could also specify that LISP nodes that receive an > ICMP error should check this checksum in the returned packet before > acting on the error. > > We would still have to make sure that we understand the impacts of > non-LISP nodes receiving corrupted LISP packets (which will probably > be that the packet is dropped, which is fine), but we wouldn't have > to worry about what happens when a LISP packet arrives at the wrong > LISP node and/or when a response is sent back to the wrong LISP node. > > Thoughts? Adding a checksum in the LISP header would mean either to shrink some other fields or to enlarge the existing LISP header. I am not sure that these are good ideas. Another approach is to use the UDP source port number. So far in LISP the source port number is selected using an hash function and ignored on reception. This can be changed in a checksum to be checked on the ETR. Not sure if such an approach breaks something or goes against any RFC. just my random thoughts.... Luigi > > Margaret > > On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > >> The problem is not what the ITRs and ETRs use the field for. They >> could / can use the field. >> The problem is that the UDP header was introduced specifically so >> that different flows would be different in a place that the routers >> would look when doing ECMP calculations. >> And the router to date do not use the flow label. >> Preliminary indications are that routers also won't use UDP-lite, >> because it is a different protocol, and they don't know it has port >> numbers. >> >> The simple path forward is to allow UDP with 0 checksum. >> If that is incorrect, then finding the correct path forward is >> going to be hard. >> >> Joel >> >> Brian E Carpenter wrote: >>> Hi Joel, >>> On 2009-08-05 03:08, Joel M. Halpern wrote: >>>> It has become clear with the passage of time that the description >>>> of the >>>> flow label in the original IPv6 specs served only to convince >>>> everyone >>>> not to use that field for anything. Even now, no one is sure >>>> what to do >>>> with it. >>> If you're referring to the lame appendix to RFC2460, that's exactly >>> why we wrote RFC3697. My understanding is that some stacks do set >>> the >>> flow label according to the SHOULD in RFC3697, but I'm not aware >>> of any deployed use cases (such as load balancing routers). The gap >>> is not in the basic specs but in exploitation. It's very similar to >>> what happened with the IPv4 TOS byte, and that took 20 years before >>> we (a) defined it properly and (b) began to see limited deployment, >>> as corporate VoIP took off. >>> My expectation has always been that exploitation of the flow label >>> would stay on the back burner until IPv6 deployment reached a >>> significant level, because there isn't much benefit in optimising >>> flow handling for <1% of the traffic. So I don't really see anything >>> odd in the current situation. >>> That said, I can't see any reason why ITRs and ETRs can't use >>> the flow label among themselves, in a way completely compatible >>> with RFC3697. But if their hardware engines can't include the >>> flow label in the n-tuple, that's a problem. >>> Brian >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Thu Aug 6 07:33:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BECB3A6CEA; Thu, 6 Aug 2009 07:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUxQwWleEubp; Thu, 6 Aug 2009 07:33:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8F8613A6BC0; Thu, 6 Aug 2009 07:33:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C176B43049C; Thu, 6 Aug 2009 07:33:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7672C4304A0; Thu, 6 Aug 2009 07:32:59 -0700 (PDT) Message-ID: <4A7AE99A.2010807@joelhalpern.com> Date: Thu, 06 Aug 2009 10:32:58 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Margaret Wasserman References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 14:33:01 -0000 I must be slow this morning. I am not sure which of two possible (similar) problems this checksum is supposed to help. 1) Due to in-network corruption, the LISP packet arrives at some non-LISP entity which has something listening at whatever UDP port the packet now ha as a destination. Clearly, a checksum in the LISP header won't help, since the receiver won't know there is a LISP header. 2) Due to in-network corruption, the LSP packet arrives at the wrok LISP receiver. He understands it is LISP, and does not realize it was not for him. So what? He decapsulates, looks at the contents, and says "I can't do anything with that." The LISP spec already tells us what it will do, and there is no problem. If LISP were not using UDP, we would still have this "risk". I, at least, don't see this as a problem to be solved. 2') There is some discussion of using the IPv 6 flow label instead of the UDP header for ECMP effects. If we do that, I can not see why we would suddenly decide that LISP itself needed a checksum. Yours, Joel Margaret Wasserman wrote: > > Hi Joel, > > I think I understand both sides of the UDP checksum issue now... > > We (or at least some of us) believe that it is a hard requirement to > support ECMP through legacy routing equipment. This equipment will only > identify flows using the 5-tuple described in the draft. These devices > do not know about UDP-Lite, and they couldn't usefully load balance LISP > traffic that was tunneled IP-in-IP, because there would be no source > port to use as a hash value for identification of the original flow. > > We (or at least some of us) are concerned about using UDP zero checksums > in IPv6, because of possible problems caused by corruption of the > source/destination IP addresses or the next header field. These fields > are protected in IPv4, even when UDP checksums are disabled. > > I have an idea that might work to satisfy both sets of concerns... > > What about putting a checksum field in the LISP header? We could > checksum across the IP pseudo-header (at least for IPv6), and the LISP > header. LISP nodes that receive these packets could check the checksum > and discard packets that have been corrupted. In addition to resolving > the concerns about corruption in the IPv6 header fields, this checksum > would protect the LISP header, which contains some one-bit fields and a > nonce that would be sensitive to corruption. We could also specify that > LISP nodes that receive an ICMP error should check this checksum in the > returned packet before acting on the error. > > We would still have to make sure that we understand the impacts of > non-LISP nodes receiving corrupted LISP packets (which will probably be > that the packet is dropped, which is fine), but we wouldn't have to > worry about what happens when a LISP packet arrives at the wrong LISP > node and/or when a response is sent back to the wrong LISP node. > > Thoughts? > > Margaret > > On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > >> The problem is not what the ITRs and ETRs use the field for. They >> could / can use the field. >> The problem is that the UDP header was introduced specifically so that >> different flows would be different in a place that the routers would >> look when doing ECMP calculations. >> And the router to date do not use the flow label. >> Preliminary indications are that routers also won't use UDP-lite, >> because it is a different protocol, and they don't know it has port >> numbers. >> >> The simple path forward is to allow UDP with 0 checksum. >> If that is incorrect, then finding the correct path forward is going >> to be hard. >> >> Joel >> >> Brian E Carpenter wrote: >>> Hi Joel, >>> On 2009-08-05 03:08, Joel M. Halpern wrote: >>>> It has become clear with the passage of time that the description of >>>> the >>>> flow label in the original IPv6 specs served only to convince everyone >>>> not to use that field for anything. Even now, no one is sure what >>>> to do >>>> with it. >>> If you're referring to the lame appendix to RFC2460, that's exactly >>> why we wrote RFC3697. My understanding is that some stacks do set the >>> flow label according to the SHOULD in RFC3697, but I'm not aware >>> of any deployed use cases (such as load balancing routers). The gap >>> is not in the basic specs but in exploitation. It's very similar to >>> what happened with the IPv4 TOS byte, and that took 20 years before >>> we (a) defined it properly and (b) began to see limited deployment, >>> as corporate VoIP took off. >>> My expectation has always been that exploitation of the flow label >>> would stay on the back burner until IPv6 deployment reached a >>> significant level, because there isn't much benefit in optimising >>> flow handling for <1% of the traffic. So I don't really see anything >>> odd in the current situation. >>> That said, I can't see any reason why ITRs and ETRs can't use >>> the flow label among themselves, in a way completely compatible >>> with RFC3697. But if their hardware engines can't include the >>> flow label in the n-tuple, that's a problem. >>> Brian >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From Fred.L.Templin@boeing.com Thu Aug 6 08:50:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D99E3A6DF1; Thu, 6 Aug 2009 08:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cgZEbCTs2PC; Thu, 6 Aug 2009 08:50:32 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 718433A6C80; Thu, 6 Aug 2009 08:50:32 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n76FoTHr023564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 08:50:32 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n76FoTqu003830; Thu, 6 Aug 2009 08:50:29 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n76FoTQe003826; Thu, 6 Aug 2009 08:50:29 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 08:50:29 -0700 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, 6 Aug 2009 08:50:29 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A7AE99A.2010807@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] Thread-Index: AcoWotriWOOX5NfrSE+tuub9k8oeFgACHzPg References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com><4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com><4A78F3C6.4020602@joelhalpern.com> <4A7AE99A.2010807@joelhalpern.com> From: "Templin, Fred L" To: "Joel M. Halpern" , "Margaret Wasserman" X-OriginalArrivalTime: 06 Aug 2009 15:50:29.0969 (UTC) FILETIME=[9FCDAC10:01CA16AD] Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 15:50:33 -0000 I told myself I would stay out of this, but I can't help but point out that if the SEAL-FS header were used instead of the UDP/LISP headers there would only be 4 bytes exposed to corruption instead of 16. And, if one of the SEAL-FS header fields is corrupted there is no danger of causing unpredictable behavior. The SEAL-FS header is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER|I| Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the I bit is flipped, the end result is that the ETR could send a spurious Information Request message which should cause no harm whatsoever to the ITR. If the Identification field is corrupted, the end result is that the ETR may send a control message back to the ITR with an unrecognized Identification - this would be dropped silently by the ITR. If the VER field is corrupted, there is a chance that the ETR could try to process the packet according to a different SEAL protocol version. But, LISP ITRs would only be expected to implement VER=3D0 anyway so the packet would simply be dropped. All this, plus a tidy 12 bytes per-packet saved over what the existing UDP/LISP encapsulation gives. Fred fred.l.templin@boeing.com=20 From mrw@sandstorm.net Thu Aug 6 09:16:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118AA3A694C; Thu, 6 Aug 2009 09:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UXwX7H4KicQ; Thu, 6 Aug 2009 09:16:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 113F73A6BE2; Thu, 6 Aug 2009 09:16:49 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n76GFQ2e014238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2009 12:15:26 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <094E1FE8-745B-46A4-9E04-3BD595DFC036@sandstorm.net> From: Margaret Wasserman To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 12:15:25 -0400 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com><4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com><4A78F3C6.4020602@joelhalpern.com> <4A7AE99A.2010807@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 16:16:51 -0000 Hi Fred, There are three things we are trying to address here: - We want to support load balancing through legacy systems that only support load balancing based on the 5-tuple of IP src/dest address, protocol/next header and UDP or TCP src/dest ports. To meet this goal, we need a UDP (or TCP) header, so that we can prevent all LISP packets between a single ITR/ETR pair from being seen as a single flow. - But, we don't want to pay the cost of checksumming the entire UDP payload (including the LISP header and the encapsulated packet). To avoid this, the current proposal states that we will use UDP with zero checksums. - However, we are concerned about using UDP with zero checksums in IPv6, because there would be no checksum protection for the IPv6 header fields (src/dest port and next header). These fields are protected by the IP header checksum in IPv4. Some people are also concerned about making sure that LISP is compatible with other IETF RFCs, which currently say that there won't be zero UDP checksums in IPv6. So, we need to figure out what to do. Once we have all of the facts on the table, we'll probably have to make a hard decision and compromise on some of the above goals. It seems to me that our proposal to move to a different LISP header format is a non-starter, because it doesn't address any of these issues/tradeoffs. Margaret On Aug 6, 2009, at 11:50 AM, Templin, Fred L wrote: > I told myself I would stay out of this, but I can't help > but point out that if the SEAL-FS header were used instead > of the UDP/LISP headers there would only be 4 bytes exposed > to corruption instead of 16. And, if one of the SEAL-FS > header fields is corrupted there is no danger of causing > unpredictable behavior. > > The SEAL-FS header is formatted as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |VER|I| Identification | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > If the I bit is flipped, the end result is that the ETR > could send a spurious Information Request message which > should cause no harm whatsoever to the ITR. If the > Identification field is corrupted, the end result is that > the ETR may send a control message back to the ITR with > an unrecognized Identification - this would be dropped > silently by the ITR. If the VER field is corrupted, there > is a chance that the ETR could try to process the packet > according to a different SEAL protocol version. But, LISP > ITRs would only be expected to implement VER=0 anyway so > the packet would simply be dropped. > > All this, plus a tidy 12 bytes per-packet saved over what > the existing UDP/LISP encapsulation gives. > > Fred > fred.l.templin@boeing.com > From jnc@mercury.lcs.mit.edu Thu Aug 6 10:00:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1420E28B797; Thu, 6 Aug 2009 10:00:13 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fow5im56CvOF; Thu, 6 Aug 2009 10:00:12 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4F3383A6D6C; Thu, 6 Aug 2009 10:00:12 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 58C316BE567; Thu, 6 Aug 2009 13:00:14 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090806170014.58C316BE567@mercury.lcs.mit.edu> Date: Thu, 6 Aug 2009 13:00:14 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 17:00:13 -0000 > From: Brian E Carpenter > I see no particular issue with a network where some LAG-aware routers > do include the flow label in the hash and others don't. Any time you have a network which is using hop-by-hop path selection (i.e. each node makes an independent decision on the next hop) and those nodes are not all using i) the same algorithm on ii) the same data, you can have routing loops. Not saying we'll necessarily get any in this case, but your statement, as written, might be questionable. Noel From jnc@mercury.lcs.mit.edu Thu Aug 6 10:11:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8443A6BBB; Thu, 6 Aug 2009 10:11:09 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhKAG30Inuzt; Thu, 6 Aug 2009 10:11:07 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D22B33A697F; Thu, 6 Aug 2009 10:11:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 83E786BE567; Thu, 6 Aug 2009 13:11:10 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090806171110.83E786BE567@mercury.lcs.mit.edu> Date: Thu, 6 Aug 2009 13:11:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 17:11:09 -0000 > From: Margaret Wasserman > In addition ... this checksum would protect the LISP header, which > contains some one- bit fields and a nonce that would be sensitive to > corruption. This is an issue I had identified a while back, and looked then to see if undetected errors in the LISP user-data-packet header could cause any problems, and as fas as I can see they can't. (I won't do the whole analysis here - we should take it offline to the LISP list only; I'm still holding on detailed analysis of the reachability vector in case it is replace by versioning.) Noel From luigi@net.t-labs.tu-berlin.de Thu Aug 6 10:25:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300673A6DDC; Thu, 6 Aug 2009 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.733 X-Spam-Level: X-Spam-Status: No, score=-3.733 tagged_above=-999 required=5 tests=[AWL=2.866, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+6-ugrsPjOD; Thu, 6 Aug 2009 10:25:12 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id BA9AF3A7218; Thu, 6 Aug 2009 10:25:00 -0700 (PDT) Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id FA.45.06316.EE11B7A4; Thu, 6 Aug 2009 13:25:02 -0400 (EDT) Received: from mail pickup service by XCH38YKF.rim.net with Microsoft SMTPSVC; Thu, 6 Aug 2009 13:24:30 -0400 Received: from mhs48ykf.rim.net ([10.64.31.134]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 10:51:14 -0400 Received: from mhs21ykf.rim.net ([10.250.46.23]) by mhs48ykf.rim.net with ESMTP; 06 Aug 2009 10:51:08 -0400 X-AuditID: 0a401fcb-b7bbbae0000018ac-96-4a7b11eecab0 Received: from mail.ietf.org ( [64.170.98.32]) by mhs21ykf.rim.net (RIM Mail) with SMTP id F5.E4.30085.CDDEA7A4; Thu, 6 Aug 2009 10:51:08 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0CE28C189; Thu, 6 Aug 2009 07:50:13 -0700 (PDT) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96A03A6AC5; Thu, 6 Aug 2009 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YTj-uRB6WBc; Thu, 6 Aug 2009 07:22:44 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 252753A698E; Thu, 6 Aug 2009 07:22:42 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 13D507064D70; Thu, 6 Aug 2009 16:22:43 +0200 (CEST) Message-Id: From: Luigi Iannone To: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Aug 2009 16:22:42 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 06 Aug 2009 07:50:12 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list content-transfer-encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Brightmail-Tracker: AAAAAgAAAZEQPFwE X-OriginalArrivalTime: 06 Aug 2009 14:51:14.0938 (UTC) FILETIME=[58D6FDA0:01CA16A5] Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@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, 06 Aug 2009 17:25:13 -0000 On Aug 6, 2009, at 16:11 , Margaret Wasserman wrote: > > Hi Joel, > > I think I understand both sides of the UDP checksum issue now... > > We (or at least some of us) believe that it is a hard requirement to > support ECMP through legacy routing equipment. This equipment will > only identify flows using the 5-tuple described in the draft. These > devices do not know about UDP-Lite, and they couldn't usefully load > balance LISP traffic that was tunneled IP-in-IP, because there would > be no source port to use as a hash value for identification of the > original flow. > > We (or at least some of us) are concerned about using UDP zero > checksums in IPv6, because of possible problems caused by corruption > of the source/destination IP addresses or the next header field. > These fields are protected in IPv4, even when UDP checksums are > disabled. > > I have an idea that might work to satisfy both sets of concerns... > > What about putting a checksum field in the LISP header? We could > checksum across the IP pseudo-header (at least for IPv6), and the > LISP header. LISP nodes that receive these packets could check the > checksum and discard packets that have been corrupted. In addition > to resolving the concerns about corruption in the IPv6 header > fields, this checksum would protect the LISP header, which contains > some one-bit fields and a nonce that would be sensitive to > corruption. We could also specify that LISP nodes that receive an > ICMP error should check this checksum in the returned packet before > acting on the error. > > We would still have to make sure that we understand the impacts of > non-LISP nodes receiving corrupted LISP packets (which will probably > be that the packet is dropped, which is fine), but we wouldn't have > to worry about what happens when a LISP packet arrives at the wrong > LISP node and/or when a response is sent back to the wrong LISP node. > > Thoughts? Adding a checksum in the LISP header would mean either to shrink some other fields or to enlarge the existing LISP header. I am not sure that these are good ideas. Another approach is to use the UDP source port number. So far in LISP the source port number is selected using an hash function and ignored on reception. This can be changed in a checksum to be checked on the ETR. Not sure if such an approach breaks something or goes against any RFC. just my random thoughts.... Luigi > > Margaret > > On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote: > >> The problem is not what the ITRs and ETRs use the field for. They >> could / can use the field. >> The problem is that the UDP header was introduced specifically so >> that different flows would be different in a place that the routers >> would look when doing ECMP calculations. >> And the router to date do not use the flow label. >> Preliminary indications are that routers also won't use UDP-lite, >> because it is a different protocol, and they don't know it has port >> numbers. >> >> The simple path forward is to allow UDP with 0 checksum. >> If that is incorrect, then finding the correct path forward is >> going to be hard. >> >> Joel >> >> Brian E Carpenter wrote: >>> Hi Joel, >>> On 2009-08-05 03:08, Joel M. Halpern wrote: >>>> It has become clear with the passage of time that the description >>>> of the >>>> flow label in the original IPv6 specs served only to convince >>>> everyone >>>> not to use that field for anything. Even now, no one is sure >>>> what to do >>>> with it. >>> If you're referring to the lame appendix to RFC2460, that's exactly >>> why we wrote RFC3697. My understanding is that some stacks do set >>> the >>> flow label according to the SHOULD in RFC3697, but I'm not aware >>> of any deployed use cases (such as load balancing routers). The gap >>> is not in the basic specs but in exploitation. It's very similar to >>> what happened with the IPv4 TOS byte, and that took 20 years before >>> we (a) defined it properly and (b) began to see limited deployment, >>> as corporate VoIP took off. >>> My expectation has always been that exploitation of the flow label >>> would stay on the back burner until IPv6 deployment reached a >>> significant level, because there isn't much benefit in optimising >>> flow handling for <1% of the traffic. So I don't really see anything >>> odd in the current situation. >>> That said, I can't see any reason why ITRs and ETRs can't use >>> the flow label among themselves, in a way completely compatible >>> with RFC3697. But if their hardware engines can't include the >>> flow label in the n-tuple, that's a problem. >>> Brian >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From Fred.L.Templin@boeing.com Thu Aug 6 10:42:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903A63A6B27; Thu, 6 Aug 2009 10:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8dHSZI1SraD; Thu, 6 Aug 2009 10:42:13 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9241A3A6A24; Thu, 6 Aug 2009 10:42:13 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n76HgDY2025058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 12:42:13 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n76HgD1q004872; Thu, 6 Aug 2009 12:42:13 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n76Hg7lD004631; Thu, 6 Aug 2009 12:42:13 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 10:42:12 -0700 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, 6 Aug 2009 10:42:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106414718@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <094E1FE8-745B-46A4-9E04-3BD595DFC036@sandstorm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] Thread-Index: AcoWsVLBPTFa7OQ6SlKeIVKUlrFlWwAC6KjQ References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com><4A784EEF.2020405@joelhalpern.com><4A78B51C.2010902@gmail.com><4A78F3C6.4020602@joelhalpern.com><4A7AE99A.2010807@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> <094E1FE8-745B-46A4-9E04-3BD595DFC036@sandstorm.net> From: "Templin, Fred L" To: "Margaret Wasserman" X-OriginalArrivalTime: 06 Aug 2009 17:42:12.0080 (UTC) FILETIME=[3A92A700:01CA16BD] Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 17:42:14 -0000 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@sandstorm.net] > Sent: Thursday, August 06, 2009 9:15 AM > To: Templin, Fred L > Cc: ipv6@ietf.org; lisp@ietf.org > Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] >=20 >=20 > Hi Fred, >=20 > There are three things we are trying to address here: >=20 > - We want to support load balancing through legacy systems that only > support load balancing based on the 5-tuple of IP src/dest address, > protocol/next header and UDP or TCP src/dest ports. To meet this goal, > we need a UDP (or TCP) header, so that we can prevent all LISP packets > between a single ITR/ETR pair from being seen as a single flow. How are non-TCP/UDP flows handled by these legacy systems today? For example, 6to4 uses ip-proto-41. Thanks - Fred fred.l.templin@boeing.com > - But, we don't want to pay the cost of checksumming the entire UDP > payload (including the LISP header and the encapsulated packet). To > avoid this, the current proposal states that we will use UDP with zero > checksums. >=20 > - However, we are concerned about using UDP with zero checksums in > IPv6, because there would be no checksum protection for the IPv6 > header fields (src/dest port and next header). These fields are > protected by the IP header checksum in IPv4. Some people are also > concerned about making sure that LISP is compatible with other IETF > RFCs, which currently say that there won't be zero UDP checksums in > IPv6. >=20 > So, we need to figure out what to do. Once we have all of the facts > on the table, we'll probably have to make a hard decision and > compromise on some of the above goals. >=20 > It seems to me that our proposal to move to a different LISP header > format is a non-starter, because it doesn't address any of these > issues/tradeoffs. >=20 > Margaret >=20 >=20 >=20 > On Aug 6, 2009, at 11:50 AM, Templin, Fred L wrote: >=20 > > I told myself I would stay out of this, but I can't help > > but point out that if the SEAL-FS header were used instead > > of the UDP/LISP headers there would only be 4 bytes exposed > > to corruption instead of 16. And, if one of the SEAL-FS > > header fields is corrupted there is no danger of causing > > unpredictable behavior. > > > > The SEAL-FS header is formatted as follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |VER|I| Identification | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > If the I bit is flipped, the end result is that the ETR > > could send a spurious Information Request message which > > should cause no harm whatsoever to the ITR. If the > > Identification field is corrupted, the end result is that > > the ETR may send a control message back to the ITR with > > an unrecognized Identification - this would be dropped > > silently by the ITR. If the VER field is corrupted, there > > is a chance that the ETR could try to process the packet > > according to a different SEAL protocol version. But, LISP > > ITRs would only be expected to implement VER=3D0 anyway so > > the packet would simply be dropped. > > > > All this, plus a tidy 12 bytes per-packet saved over what > > the existing UDP/LISP encapsulation gives. > > > > Fred > > fred.l.templin@boeing.com > > >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Thu Aug 6 13:10:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E5F3A6D9F; Thu, 6 Aug 2009 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgJdAW9ORHFk; Thu, 6 Aug 2009 13:10:12 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C741C3A6DE0; Thu, 6 Aug 2009 13:09:45 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n76K9bir023515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2009 16:09:38 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106414718@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 16:09:37 -0400 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com><4A784EEF.2020405@joelhalpern.com><4A78B51C.2010902@gmail.com><4A78F3C6.4020602@joelhalpern.com><4A7AE99A.2010807@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> <094E1FE8-745B-46A4-9E04-3BD595DFC036@sandstorm.net> <39C363776A4E8C4A94691D2BD9D1C9A106414718@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 20:10:13 -0000 Hi Fred, On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote: > > How are non-TCP/UDP flows handled by these legacy systems > today? For example, 6to4 uses ip-proto-41. My understanding is that these flows will not be handled well... Since ECMP load balancers will have limited information available (the two IP address and the next header value), they will group all of the traffic between two 6to4 tunnel endpoints into a single flow. If it becomes common for pairs of tunnel endpoints to transmit large amounts of data across ISP networks, this could present a significant operational issue for the Internet. This problem (and the LISP problem) could potentially be alleviated by hardware that performs load balancing based on the IP address, the next header and the IPv6 flow label. But, according to folks who ought to know, most of the IPv6 routers they have deployed can't handle load balancing based on anything but a UDP or TCP 5-tuple, even in IPv6 (no IPv6 flow label, no UDP-Lite, no SCTP, etc.). This is rather distressing, but I have no reason to doubt their statements. Margaret From brian.e.carpenter@gmail.com Thu Aug 6 14:32:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1CB3A69A4; Thu, 6 Aug 2009 14:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caP+SAXAc80Y; Thu, 6 Aug 2009 14:32:05 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 3998E3A6850; Thu, 6 Aug 2009 14:32:05 -0700 (PDT) Received: by pzk42 with SMTP id 42so1222885pzk.17 for ; Thu, 06 Aug 2009 14:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=f80L+2j/3V8yGcIxGzEBKVAf40x2MJPrlTS96P6RXFk=; b=hL+LSyF09g/dgeuJjyGTj8I7iuUo5p4rU5rwfeKaptt79TcCxdMVAy0zCzqOKopcUK MtMZGpwxwEjuPALjlcRCt9Mh8Gixq8CgYXRv+/8rJ8cfV8b9xskqMeqdfdFoIWUbHlDR 3YZrygy9KSUVWsB6EBuEcPtELfn6mQq4MUk4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GibO5pstxAdI1qfSms+HCnp6PgULcQIQ8e0pj93CR2WlzQyeIrj5HTIRzUlLjyyE6E B5gzW75MhV0//AAKK9gqHHHpjiobEsMG6u0JwXkUIeE4lMQXSFfcbmgXAvyA/AEETHWJ 9mg949cCBjlBO1+NoOKpyELq7Ya6cqCRG0GYQ= Received: by 10.115.55.13 with SMTP id h13mr128124wak.99.1249594326068; Thu, 06 Aug 2009 14:32:06 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k14sm611415waf.25.2009.08.06.14.32.03 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Aug 2009 14:32:05 -0700 (PDT) Message-ID: <4A7B4BD2.2010602@gmail.com> Date: Fri, 07 Aug 2009 09:32:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shane Amante References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> <4A7A59E9.9070900@gmail.com> <5DA47DB3-0925-4F83-A1C2-E998B3735334@castlepoint.net> In-Reply-To: <5DA47DB3-0925-4F83-A1C2-E998B3735334@castlepoint.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label collision [Flow label redux [Re: IPv6 UDP checksum issue]] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 21:32:06 -0000 Shane, On 2009-08-07 01:40, Shane Amante wrote: > Brian, > > On Aug 5, 2009, at 22:19 MDT, Brian E Carpenter wrote: >> On 2009-08-06 05:34, Christopher Morrow wrote: >> ... >>>> 2) Removing other "gems" (or clarifying them) like the second >>>> sentence in >>>> the following: >>>> ---cut here--- >>>> IPv6 nodes MUST NOT assume any mathematical or other properties of >>>> the Flow >>>> Label >>>> values assigned by source nodes. Router performance SHOULD NOT be >>>> dependent >>>> on the >>>> distribution of the Flow Label values. Especially, the Flow Label >>>> bits alone >>>> make >>>> poor material for a hash key. >>>> ---cut here--- >>> >>> 'flow label bits alone make a poor material for a hash key'... isn't >>> this the reverse of saying that we'll (operators) require vendors to >>> use flow-label for hashing on ECMP/LAG? If so, then... I don't think >>> flow-label's going to cut it. >> >> Please note the word "alone" in the above extract from RFC3697. > > I think Chris may have read that a little too fast. :-) I wasn't > concerned with the third sentence in the RFC, that makes sense and is > clear. However, my concern was pertaining to the 2nd sentence, > specifically: "Router performance SHOULD NOT be dependent on the > distribution of the Flow Label values". Specifically, if Flow Label > values ARE used as one of the input-keys (in addition to src/dst IPv6 > addresses), then the "distribution" of Flow Label values matters /a lot/ > in order to achieve "good" load-balancing over LAG/ECMP paths and, > consequently, good router performance. However, perhaps I'm > misreading/misunderstanding that 2nd sentence. Can you clarify it's > intent? Pekka just did that, I think - the flow label will add value if it happens to increase the randomness of the hash, but this can't be relied on so we shouldn't depend on it. Brian From jnc@mercury.lcs.mit.edu Thu Aug 6 15:11:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AF928C155; Thu, 6 Aug 2009 15:11:21 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s6BfMLcmPty; Thu, 6 Aug 2009 15:11:20 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4F64228C146; Thu, 6 Aug 2009 15:11:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 83CF36BE56B; Thu, 6 Aug 2009 18:11:22 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090806221122.83CF36BE56B@mercury.lcs.mit.edu> Date: Thu, 6 Aug 2009 18:11:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 22:11:21 -0000 > From: Havard Eidnes > in this specific example which is talking about a Link Aggregation > Group (LAG). I did indeed miss that detail. The conversation had been about a collection of similar things, including ECMP, and I was thinking of that broader class of things in making that comment. Noel From Fred.L.Templin@boeing.com Thu Aug 6 15:30:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6077A3A6D92; Thu, 6 Aug 2009 15:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RODzyoxyFlmy; Thu, 6 Aug 2009 15:30:20 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 8F13B3A6C67; Thu, 6 Aug 2009 15:30:20 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n76MUGA6001869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 15:30:19 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n76MUG2S016173; Thu, 6 Aug 2009 15:30:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n76MU3Y6015087; Thu, 6 Aug 2009 15:30:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 15:30:15 -0700 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, 6 Aug 2009 15:30:13 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10641494E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] Thread-Index: AcoW0diTDm7qU6IHSCeJzdGthOIE/wAEvA/w References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com><4A784EEF.2020405@joelhalpern.com><4A78B51C.2010902@gmail.com><4A78F3C6.4020602@joelhalpern.com><4A7AE99A.2010807@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A1064145E9@XCH-NW-7V2.nw.nos.boeing.com> <094E1FE8-745B-46A4-9E04-3BD595DFC036@sandstorm.net> <39C363776A4E8C4A94691D2BD9D1C9A106414718@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Margaret Wasserman" X-OriginalArrivalTime: 06 Aug 2009 22:30:15.0303 (UTC) FILETIME=[782D3170:01CA16E5] Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 22:30:21 -0000 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@sandstorm.net] > Sent: Thursday, August 06, 2009 1:10 PM > To: Templin, Fred L > Cc: ipv6@ietf.org; lisp@ietf.org > Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] >=20 >=20 > Hi Fred, >=20 > On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote: > > > > How are non-TCP/UDP flows handled by these legacy systems > > today? For example, 6to4 uses ip-proto-41. >=20 > My understanding is that these flows will not be handled well... > Since ECMP load balancers will have limited information available (the > two IP address and the next header value), they will group all of the > traffic between two 6to4 tunnel endpoints into a single flow. If it > becomes common for pairs of tunnel endpoints to transmit large amounts > of data across ISP networks, this could present a significant > operational issue for the Internet. >=20 > This problem (and the LISP problem) could potentially be alleviated by > hardware that performs load balancing based on the IP address, the > next header and the IPv6 flow label. But, according to folks who ought > to know, most of the IPv6 routers they have deployed can't handle load > balancing based on anything but a UDP or TCP 5-tuple, even in IPv6 (no > IPv6 flow label, no UDP-Lite, no SCTP, etc.). This is rather > distressing, but I have no reason to doubt their statements. I guess add IPSec to the list of flows that would not be handled well in the future? Are you saying that we need to accept that the Internet is ossified, and all new protocols will need to continue to do things the old way? Fred fred.l.templin@boeing.com >=20 > Margaret >=20 From jnc@mercury.lcs.mit.edu Thu Aug 6 15:44:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398CB3A6D6E for ; Thu, 6 Aug 2009 15:44:54 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9trXs2u7OeZo for ; Thu, 6 Aug 2009 15:44:53 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0C6B428C104 for ; Thu, 6 Aug 2009 15:44:19 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3268A6BE56B; Thu, 6 Aug 2009 18:44:22 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> Date: Thu, 6 Aug 2009 18:44:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 22:44:54 -0000 > From: Margaret Wasserman > concerned about using UDP with zero checksums in IPv6, because there > would be no checksum protection for the IPv6 header fields (src/dest > port and next header). I guess I don't see that there's a big problem here, if the _outer_ IPv6 header is damaged. The inner packet (either v4, or v6) will still have its checksum(s) to protect it. I'm trying to understand what all the possible failure modes are if the outer header is damaged. Here are the ones I can think of: - The packet may arrive at the wrong destination, which should either i) not recognize it (because it's not an ETR - I don't recall if LISP uses registered ports, if not at some point we should apply for some), or ii) unwrap it and discover that that EID is not at that ETR (which is a failure that can happen for other reasons, so has to be handled). - The packet may arrive with a damaged source address. This may cause a bogus 'partner ITR' entry to be created (e.g. for the echo nonce entry), but I can't think of any real problems that will happen in this case. Maybe I'm not very awake today, but that's all I can come up with off the top of my head? Other errors (e.g. bashing the hop count) may cause the packet to be discarded in transit, but that can happen anyway. In general, the reliance on explict control traffic (which is protected from error by checksums - "The UDP Checksum is computed and set to non-zero for Map-Request and Map-Reply messages") for most functions should help with robustness. There are a _few_ functions which are piggybacked on user data traffic, and as alluded to in a prior message, we do have to be careful in designing them, to make sure they aren't affectable by damaged headers. So far that has been no problem. Noel From tme@americafree.tv Thu Aug 6 19:05:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC73F3A69A2 for ; Thu, 6 Aug 2009 19:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOnxgFoQxMmv for ; Thu, 6 Aug 2009 19:05:29 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0A6353A694D for ; Thu, 6 Aug 2009 19:05:28 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id CC1A346B9C7D; Thu, 6 Aug 2009 22:05:31 -0400 (EDT) Message-Id: From: Marshall Eubanks To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 22:05:29 -0400 References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 02:05:30 -0000 On Aug 6, 2009, at 6:44 PM, Noel Chiappa wrote: >> From: Margaret Wasserman > >> concerned about using UDP with zero checksums in IPv6, because there >> would be no checksum protection for the IPv6 header fields (src/dest >> port and next header). > > I guess I don't see that there's a big problem here, if the _outer_ > IPv6 > header is damaged. The inner packet (either v4, or v6) will still > have its > checksum(s) to protect it. This is more than just LISP. Any relaxation of the IPv6 header checksum will be an update of RFC2460 and will be applicable to more uses than just LISP. However, I do not think that this changes your argument too much. Regards Marshall > > > I'm trying to understand what all the possible failure modes are if > the outer > header is damaged. Here are the ones I can think of: > > - The packet may arrive at the wrong destination, which should > either i) not > recognize it (because it's not an ETR - I don't recall if LISP uses > registered ports, if not at some point we should apply for some), or > ii) > unwrap it and discover that that EID is not at that ETR (which is a > failure > that can happen for other reasons, so has to be handled). > > - The packet may arrive with a damaged source address. This may > cause a > bogus 'partner ITR' entry to be created (e.g. for the echo nonce > entry), > but I can't think of any real problems that will happen in this case. > > Maybe I'm not very awake today, but that's all I can come up with > off the top > of my head? Other errors (e.g. bashing the hop count) may cause the > packet to > be discarded in transit, but that can happen anyway. > > > In general, the reliance on explict control traffic (which is > protected from > error by checksums - "The UDP Checksum is computed and set to non- > zero for > Map-Request and Map-Reply messages") for most functions should help > with > robustness. > > There are a _few_ functions which are piggybacked on user data > traffic, and > as alluded to in a prior message, we do have to be careful in > designing them, > to make sure they aren't affectable by damaged headers. So far that > has > been no problem. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Thu Aug 6 19:38:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BE33A67B7 for ; Thu, 6 Aug 2009 19:38:35 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjcqa99OgjKB for ; Thu, 6 Aug 2009 19:38:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 54F1D3A6897 for ; Thu, 6 Aug 2009 19:38:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 30D2C6BE56F; Thu, 6 Aug 2009 22:38:36 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090807023836.30D2C6BE56F@mercury.lcs.mit.edu> Date: Thu, 6 Aug 2009 22:38:36 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 02:38:35 -0000 > From: Marshall Eubanks > This is more than just LISP. Any relaxation of the IPv6 header checksum > will be an update of RFC2460 and will be applicable to more uses than > just LISP. My message was about the technical issues. I personally am utterly uninterested in the overly-bureacratic standards-process red-tape hoops. If you have technical insight to offer on the topic covered in that message - i.e. the consequences of undetected damage to the outer internetwork layer header - I would, however, be most interested in that. Noel From iljitsch@muada.com Fri Aug 7 02:34:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A033A67FF; Fri, 7 Aug 2009 02:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+XQ4GeoE1pe; Fri, 7 Aug 2009 02:34:44 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E645B3A6A5A; Fri, 7 Aug 2009 02:34:43 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n779YKuW064884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 11:34:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <5070C70F-5FF4-42EB-964B-995BF65410B1@muada.com> From: Iljitsch van Beijnum To: Noel Chiappa In-Reply-To: <20090806170014.58C316BE567@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 11:34:09 +0200 References: <20090806170014.58C316BE567@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 09:34:45 -0000 On 6 aug 2009, at 19:00, Noel Chiappa wrote: >> I see no particular issue with a network where some LAG-aware routers >> do include the flow label in the hash and others don't. > Any time you have a network which is using hop-by-hop path selection > (i.e. > each node makes an independent decision on the next hop) and those > nodes are > not all using i) the same algorithm on ii) the same data, you can > have routing > loops. Depends on whether you are using strong multipath routing or weak multipath routing. (I hope there is better existing terminology for this, but haven't found it so far.) Consider: A B | | +------+ | | | | | | +------+ | | C D In the strong multipath routing case traffic from C to A can flow directly and C-D-B-A. So far so good. But D's traffic can flow D-C-A and D-B-A. This means that traffic towards A will flow over the C-D link in BOTH directions. This can only happen when C and D can determine for each packet whether it is on the C-D-B-A path or the D-C- A path. So there must be something in the packet that determines this and that is interpreted the same way by C and D. In the weak multipath routing case this problem doesn't exist, because packets towards a certain destination may only traverse a certain link in one direction. At this point, you won't be surprised to learn that existing multipath routing techniques, including link aggregation load balancing of various kinds, tend to use weak multipath routing. The exception is OSPF ToS routing, which uses the type-of-service bits to keep things straight. (Don't remember how the new and improved OSPF multitopology routing does this...) From iljitsch@muada.com Fri Aug 7 02:47:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B413A6ECB; Fri, 7 Aug 2009 02:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxR+6EUYtD59; Fri, 7 Aug 2009 02:47:32 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 44A4F3A6EC5; Fri, 7 Aug 2009 02:47:32 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n779l8XU064968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 11:47:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <31AD4990-1ABF-48E1-AE8F-4438B98A82C4@muada.com> From: Iljitsch van Beijnum To: Margaret Wasserman In-Reply-To: <28077E14-4F07-4CB4-8AA4-5F6EA9886063@lilacglade.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 11:47:25 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <28077E14-4F07-4CB4-8AA4-5F6EA9886063@lilacglade.org> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 09:47:33 -0000 On 5 aug 2009, at 16:16, Margaret Wasserman wrote: > What I am asking is whether IPv6 routers containing that silicon > exist in real-world deployments in large enough numbers that they > should be considered in our design choices. The real question is how many of these routers use parallel links towards other IPv6 routers where balancing traffic on the 3-tuple (addresses + next header) wouldn't provide sufficient balancing of the traffic over the links. Assuming a reasonable number of different hosts communicating through the link bundle, this will only be problematic when any two hosts are responsible for a significant fraction of the bandwidth of an individual link, but communicate using multiple sessions. If we assume these are at least 1 Gbps, we'd only have trouble when a single host has several 200 Mbps+ session to another IPv6 host through the link bundle. Considering the fact that the total native IPv6 traffic through the AMS-IX currently peaks at around 1.5 Gbps I manage to not lose sleep over the risk of not being able to load balance more granularly than on the 3-tuple in IPv6 currently. From iljitsch@muada.com Fri Aug 7 02:52:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3277128C16F; Fri, 7 Aug 2009 02:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYS4S2H+OqLi; Fri, 7 Aug 2009 02:52:44 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 3E77A28C165; Fri, 7 Aug 2009 02:52:44 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n779qEQR064998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 11:52:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Christopher Morrow In-Reply-To: <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 11:52:03 +0200 References: <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 09:52:45 -0000 On 5 aug 2009, at 19:34, Christopher Morrow wrote: > You may see 2-3 year cycle on new asics for this feature to appear... > given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before > hardware is on the shelf to purchase. You assume this requires new hardware. Although that's not inconceivable, I would think that in most cases a software or microcode update would be sufficient. > 'flow label bits alone make a poor material for a hash key'... isn't > this the reverse of saying that we'll (operators) require vendors to > use flow-label for hashing on ECMP/LAG? If so, then... I don't think > flow-label's going to cut it. Huh? By the way, if we want good load balancing in IPv6 it's always possible to use more source/destination address pairs, as addresses are cheap in IPv6. From hartmans@mit.edu Fri Aug 7 04:36:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BB03A6EF4 for ; Fri, 7 Aug 2009 04:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwySbmqkKupZ for ; Fri, 7 Aug 2009 04:36:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E4A483A67EC for ; Fri, 7 Aug 2009 04:36:09 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8DAC4641DA; Fri, 7 Aug 2009 07:35:52 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> From: Sam Hartman Date: Fri, 07 Aug 2009 07:35:52 -0400 In-Reply-To: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu\, 6 Aug 2009 18\:44\:22 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 11:36:10 -0000 Speaking as an individual for the moment: >>>>> "Noel" == Noel Chiappa writes: Noel> - The packet may arrive with a damaged source address. This Noel> may cause a bogus 'partner ITR' entry to be created Noel> (e.g. for the echo nonce entry), but I can't think of any Noel> real problems that will happen in this case. I'm sending this message, mainly to indicate that the problem of outer header corruption is one that requires real technical thought and that has non-obvious consequences. It may well be that we can design a LISP for which the possibility of outer header corruption is acceptable and for which we can convince ourselves of this fact. However it's fairly easy for me to illustrate this requires actual work and thought. Under the current lisp-03 spec, an ETR receiving such a packet is allowed to create a gleaned cache entry for the source EID in the packet, using the outer RLOC (the corrupted source IP address) for communication with that EID. Nothing in the current spec mandates that the ETR send a confirming map-request, and I believe the default TTL is rather long. Ignore for the moment that by the time we get done discussing security, the behavior may be somewhat different:-) It is clearly the case with today's LISP spec that a single corrupted packet is permitted to disrupt communications between two lisp nodes for a significant period of time. This illustrates that it is very easy to design a protocol for which this sort of corruption is easy. Thus, I believe that the kind of analysis Margaret is asking for needs to be performed carefully and fully. I for one will disregard any message claiming that outer header corruption is not a problem if it includes the words "obvious," "easy," is generally dismissive of the problem, or is not thoroughly detailed. I want to stress that your message was a great technical contribution: you were trying to find an easy way to dismiss a concern so we could go onto other issues. My problem is that after spending an hour or so looking at the current LISP spec with regard to this issue, I've come to the conclusion that there is no such easy mechanism. From jnc@mercury.lcs.mit.edu Fri Aug 7 05:27:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E1E3A6F20 for ; Fri, 7 Aug 2009 05:27:34 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnGM9gTMRGMW for ; Fri, 7 Aug 2009 05:27:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 001F73A6F13 for ; Fri, 7 Aug 2009 05:27:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 266556BE55F; Fri, 7 Aug 2009 08:27:36 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090807122736.266556BE55F@mercury.lcs.mit.edu> Date: Fri, 7 Aug 2009 08:27:36 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 12:27:35 -0000 > From: Sam Hartman > Under the current lisp-03 spec, an ETR receiving such a packet is > allowed to create a gleaned cache entry for the source EID in the > packet, using the outer RLOC .. for communication with that EID. > > Nothing in the current spec mandates that the ETR send a confirming > map-request, and I believe the default TTL is rather long. Is that [still] in the spec? (I've seen so many versions of the main spec document I have a hard time forcing myself to read them any more! :-) If it's still there, yes, it's an issue. I thought that that was either i) something associated with other 'versions' of LISP (or perhaps 'deployment models' is more accurate terminology than "versions" - I'm talking about things like 'LISP 1', where there is no mapping system), or ii) something that had been deprecated as a DoS vector (send someone a bogus packet, and pollute their mapping cache). If in fact this is still in the spec for the main 'deployment model', there are several different potential directions to go to fix this. One is to say 'we won't do this optimization' (i.e. won't piggyback that control operation on user data traffic); another is to make sure it's reliable (i.e. mandate checksums on packets which we wish to be 'gleanable'). There are a whole bunch of variants, though. For instance, we could say 'a mapping can't be gleaned from a user-data packet with a zero checksum'; that leaves it up to the sending ITR whether it wants to bother optimizing that control interaction (which would mean doing the checksum - of course, you wouldn't want the overhead of doing that on all packets, so the sending ITR would need logic that's probably more complex than it's worth to decide when to checksum such packets - e.g. the first N packets after a mapping is looked up). Also, such gleaning is still a potential DoS vector, even if the data is not damaged, so we'd still have to deal with that aspect. Probably have text in the spec to say that such mappings are temporary optimizations, and have to be replaced by an authenticated mapping ASAP? (And in no cases should such a 'gleaned' mapping replace one that had been looked up in an authenticated manner.) Transient bogus mappings do no real harm - the choice would be between i) no mapping, and ii) a bad mapping. > you were trying to find an easy way to dismiss a concern so we could go > onto other issues. Yes and no. No, in that if there is a problem, I would like to find it - hence my comments of "Here are the ones I can think of" and "Maybe I'm not very awake today, but that's all I can come up with off the top of my head". My survey was a quick one, performed (as indicated by that comment) without checking through the spec in detail, and was intended to jump-start a technical discussion on this exact point - are there any piggy-backed control interactions that would be affected by damaged headers. Yes, in that since there are very few control interactions piggy-backed on user data traffic, and those few that there are are generally optimizations, at a high level that indicates to me that there should not be any great difficulty in making the protocol work in an environment which has the potential for damaged headers. But there is _no way_ I want to see a protocol which has any issues of this sort (or any other) go out. Sweeping problems under the rug is not a 'feature', it's highly counter-productive. Noel From jnc@mercury.lcs.mit.edu Fri Aug 7 05:41:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D343A6EE9 for ; Fri, 7 Aug 2009 05:41:04 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1w6WO7jrY4K for ; Fri, 7 Aug 2009 05:41:01 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 945063A6C03 for ; Fri, 7 Aug 2009 05:41:01 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5C39D6BE55F; Fri, 7 Aug 2009 08:41:04 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090807124104.5C39D6BE55F@mercury.lcs.mit.edu> Date: Fri, 7 Aug 2009 08:41:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 12:41:04 -0000 > Probably have text in the spec to say that such mappings are temporary > optimizations, and have to be replaced by an authenticated mapping > ASAP? ... Transient bogus mappings do no real harm - the choice would > be between i) no mapping, and ii) a bad mapping. PS: This thought applies to mappings gleaned from damaged packets, too. If every so often one gets a bad mapping in the cache, until the 'official' mapping comes through from the enquiry, that's probably still a worthwhile optimization, because i) no harm will have been done by the occasional bad mapping, and ii) in all the other instances, one's better off than waiting for the authenticated mapping to arrive. Noel From christopher.morrow@gmail.com Fri Aug 7 06:49:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C01B3A6910; Fri, 7 Aug 2009 06:49:40 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVUkBfipZfP0; Fri, 7 Aug 2009 06:49:39 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id D73133A67B4; Fri, 7 Aug 2009 06:49:32 -0700 (PDT) Received: by qyk41 with SMTP id 41so1572178qyk.29 for ; Fri, 07 Aug 2009 06:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/UJtrMLVW0tzieA6rnEmiuZ1cnbnGOMp0gBMafDd8sc=; b=Li8UEdTztHkvC84KF1VDLQs2Bsf6MWfghW+I9caAnce16TIUrt3LQyXQtguFNx8Gjc ktGbZk5Z1eYscMSvja2HNFQoWDOM0iI7g60dCz2u6JnZqvfhc2dztIKyzJljGKqkI4Mh 8qkZgfhyzFbtYP/4XHA/EFxPbrmaZiXmV3tgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HE30bUCoy3dKOrjBwHUWI81X1TV0y2cPQFQxb42clpPu0pPj9RuJxloAwarfxL/Y5w 8XkgcWk26T+vU89g4NSxgP58cThlVbPI4sYD8Z6hH5h3xYWZq1KGaxu2oDj5+LiF6hrG 9AVHL6w8+6oGDrokF9tX693ZUEOqJ/ycWuS/E= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.80.211 with SMTP id u19mr1059185qak.263.1249652973489; Fri, 07 Aug 2009 06:49:33 -0700 (PDT) In-Reply-To: References: <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <75cb24520908051034w5f08294ajdb788513a94c3fc3@mail.gmail.com> Date: Fri, 7 Aug 2009 09:49:33 -0400 X-Google-Sender-Auth: 8ef92c464fd0dde3 Message-ID: <75cb24520908070649y7da76ea3q5f4bb0d0db0a069@mail.gmail.com> From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 13:49:40 -0000 On Fri, Aug 7, 2009 at 5:52 AM, Iljitsch van Beijnum wrote: > On 5 aug 2009, at 19:34, Christopher Morrow wrote: > >> You may see 2-3 year cycle on new asics for this feature to appear... >> given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before >> hardware is on the shelf to purchase. > > You assume this requires new hardware. Although that's not inconceivable, I > would think that in most cases a software or microcode update would be > sufficient. I look forward to your microcode update ... I'm not sure that classifiers (on juniper or cisco devices) that work at 40g+ are going to be microcode upgradable. My point is that just saying: "Well, now use X. See all fixed!" isn't reality. There is atleast a 3-5 year lag. >> 'flow label bits alone make a poor material for a hash key'... isn't >> this the reverse of saying that we'll (operators) require vendors to >> use flow-label for hashing on ECMP/LAG? If so, then... I don't think >> flow-label's going to cut it. > > Huh? > brian sufficiently cleared up the wording/reasoning. > By the way, if we want good load balancing in IPv6 it's always possible to > use more source/destination address pairs, as addresses are cheap in IPv6. awesome, how do I do that dynamically and on-demand? you're imposing a restriction on the end users in order to fix this core problem, outside of LISP I mean, I'm not sure that's going to work out either (shifting costs and such). -chris From he@uninett.no Thu Aug 6 11:05:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FBF3A6B8C; Thu, 6 Aug 2009 11:05:04 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNT41S59+IGH; Thu, 6 Aug 2009 11:05:03 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by core3.amsl.com (Postfix) with ESMTP id 750E83A6E4F; Thu, 6 Aug 2009 11:04:17 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 75D953D09D; Thu, 6 Aug 2009 20:04:18 +0200 (CEST) Date: Thu, 06 Aug 2009 20:04:18 +0200 (CEST) Message-Id: <20090806.200418.13749674.he@uninett.no> To: jnc@mercury.lcs.mit.edu From: Havard Eidnes In-Reply-To: <20090806170014.58C316BE567@mercury.lcs.mit.edu> References: <20090806170014.58C316BE567@mercury.lcs.mit.edu> X-Mailer: Mew version 5.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 07 Aug 2009 09:03:42 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Aug 2009 18:05:04 -0000 > > From: Brian E Carpenter > > > I see no particular issue with a network where some LAG-aware r= outers > > do include the flow label in the hash and others don't. > > Any time you have a network which is using hop-by-hop path > selection (i.e. each node makes an independent decision on the > next hop) and those nodes are not all using i) the same > algorithm on ii) the same data, you can have routing loops. In principle you're of course correct if the flow label was entered as a factor into the layer-3 routing computation, especially if individual routers do so differently. However, I don't think that would be the case in this specific example which is talking about a Link Aggregation Group (LAG). A LAG will from the layer-3 routing perspective appear as a single point-to-point path. So... what we're talking about is primarily a link-level forwarding decision, not a layer-3 routing decision. Thus, you can't get a routing loop, even if the devices at each end of the LAG would use different algorithms for distributing the load across the member links of the LAG. While I have your collective attention, I'll just say that I sometimes could wish for more focus on speedy deployment, and to seriously consider the time it takes from "tweak to a standard" until it's either initially deployed or even worse universally deployed in operational networks. To that end I'd like to commend the LISP designers for wanting to work with existing deployed hardware, and that I would turn my thumb down to those who seem to indicate they want to not to consider the already deployed base, and in effect go back to square zero. Best regards, - H=E5vard From Francis.Dupont@fdupont.fr Fri Aug 7 08:24:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DD03A6F3F; Fri, 7 Aug 2009 08:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBKesQoj3vW6; Fri, 7 Aug 2009 08:24:40 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AD5DB28C1AF; Fri, 7 Aug 2009 08:24:22 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n77FONdo014337; Fri, 7 Aug 2009 17:24:23 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200908071524.n77FONdo014337@givry.fdupont.fr> From: Francis Dupont To: Margaret Wasserman In-reply-to: Your message of Wed, 05 Aug 2009 15:08:09 EDT. <7B439CB4-6340-4158-9AAB-62599BA43EC6@sandstorm.net> Date: Fri, 07 Aug 2009 17:24:23 +0200 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Fri, 07 Aug 2009 09:03:42 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 15:24:41 -0000 In your previous mail you wrote: And I understand that current load balancers can only do this based on a few fields: src/dest IP addresses (two RLOCs), the IP traffic class, the IP protocol field (UDP=17) and the src/dest UDP ports (xxxx and LISP=4341). I just don't see how this works very well with LISP, though... The two RLOCs are likely to be constant for all traffic between the same LISP routers, and ITR/ETR pair (right?). => in fact the IPv6 addresses don't need to be the same when xTRs are attached to regular links with /64 prefixes. So IMHO most of this discussion is insane: - if we need to vary things between a pair of IPv6 xTRs it should be enough (and simple/easy) to vary the addresses - we already have a "waste" of 2^64 addresses per links so this should never become a resource problem (:-) - the O UDP checksum proposal obsoletes all the today deployed nodes which check them (so all hosts I know and perhaps a lot of routers too), so if we believe something has to be fixed some routers should be fixed and not all BSD/Linux/MacOS/Windows boxes (software and hardware). To summary not only it is better to encourage application of RFCs than to twist them because they don't reflect the last idea, but in this case this is a total economical non-sense... Thanks Francis.Dupont@fdupont.fr PS: Margaret, the insane is not for you: your messages in this thread are clearly the most reasonnable/rational. PPS: to use the flow label (not alone) is not stupid, the 5-tuple is not always easy to extract in particular with IPv6. From shane@castlepoint.net Fri Aug 7 10:02:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923F83A6C62; Fri, 7 Aug 2009 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2bL0G3u-NEk; Fri, 7 Aug 2009 10:02:09 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A53E63A6F6A; Fri, 7 Aug 2009 10:02:09 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E4EE42684EA; Fri, 7 Aug 2009 11:02:12 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 07 Aug 2009 11:02:12 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=63764; data-bytes=0 Message-Id: <27109484-9BF9-4ED9-B40D-DCB96788B074@castlepoint.net> From: Shane Amante To: Francis Dupont In-Reply-To: <200908071524.n77FONdo014337@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 11:02:11 -0600 References: <200908071524.n77FONdo014337@givry.fdupont.fr> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 17:02:10 -0000 Francis, On Aug 7, 2009, at 09:24 MDT, Francis Dupont wrote: > In your previous mail you wrote: > > And I understand that current load balancers can only do this based > on a few fields: > src/dest IP addresses (two RLOCs), the IP traffic class, the IP > protocol field (UDP=17) and the src/dest UDP ports (xxxx and > LISP=4341). > > I just don't see how this works very well with LISP, though... The > two RLOCs are likely to be constant for all traffic between the same > LISP routers, and ITR/ETR pair (right?). > > => in fact the IPv6 addresses don't need to be the same when xTRs are > attached to regular links with /64 prefixes. So IMHO most of this > discussion is insane: :-) > - if we need to vary things between a pair of IPv6 xTRs it should > be enough (and simple/easy) to vary the addresses The above was considered at the initial design stages of LISP, (I think Dino may have considered this approach?); however, it was shot down, because this would require the installers/administrators of the LISP ITR to both know the reasons why the above is required *and* configure the IPv6 ITR's with /64's to get the load-splitting benefits across LAG/ECMP paths. (Remember the adage: "My network, my rules"). Instead, it's more 'straightforward' to just have the ITR's / automatically/ calculate a hash of the incoming IP packet and stuff that into the UDP source port before transmitting it out its uplinks toward the ETR. The key advantage of this approach is that ITR's / will/ be owned & operated by downstream customer's (i.e.: it's their CE's) who are likely unaware of and, therefore, may not care about the (extremely large) prevalence of LAG/ECMP paths through their upstream providers ... until congestion occurs in their upstream providers and they get upset. When in doubt, automatic == good. -shane > - we already have a "waste" of 2^64 addresses per links so this should > never become a resource problem (:-) > - the O UDP checksum proposal obsoletes all the today deployed nodes > which check them (so all hosts I know and perhaps a lot of routers > too), > so if we believe something has to be fixed some routers should be > fixed > and not all BSD/Linux/MacOS/Windows boxes (software and hardware). > To summary not only it is better to encourage application of RFCs > than to twist them because they don't reflect the last idea, but > in this case this is a total economical non-sense... > > Thanks > > Francis.Dupont@fdupont.fr > > PS: Margaret, the insane is not for you: your messages in this thread > are clearly the most reasonnable/rational. > PPS: to use the flow label (not alone) is not stupid, the 5-tuple is > not always easy to extract in particular with IPv6. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shane@castlepoint.net Fri Aug 7 11:05:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054DC3A6F88; Fri, 7 Aug 2009 11:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+nWpXYOOfR4; Fri, 7 Aug 2009 11:05:30 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E24313A6E9D; Fri, 7 Aug 2009 11:05:29 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 2163A2684EA; Fri, 7 Aug 2009 12:05:33 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 07 Aug 2009 12:05:33 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=64542; data-bytes=0 Message-Id: <5E383B58-3352-43F2-8903-22F8ECE7C57A@castlepoint.net> From: Shane Amante To: Margaret Wasserman In-Reply-To: <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 12:05:30 -0600 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 18:05:31 -0000 Hi Margaret, Apologies for the delay, but it took some time to follow-up with some vendors. See below. On Aug 5, 2009, at 12:33 MDT, Margaret Wasserman wrote: > Hi Shane, > > On Aug 5, 2009, at 12:50 PM, Shane Amante wrote: >> >> To bring this back up a level, while it's /possible/ to encourage >> vendors to adopt the IPv6 flow-label as input-keys to their hash- >> calculations for LAG/ECMP, it takes [a lot] of time to see that >> materialize in the field. Practically, you're probably looking at >> somewhere between, at best, a 3 - 5 year window, before it will >> actually appear in live, production networks, given that it has to >> be prioritized for development at the vendor, tested, released in >> software, then re-tested by the SP and, finally, deployed. That's >> not an "easy" process that happens in the blink-of-an-eye. That's >> not to say that we (SP's) should not "encourage" vendors to do >> this, anyway, (we are/will) however if LISP (or other protocols >> like it that depend on tunneling) quickly gain traction, we need a >> way to deal with these traffic flows in our networks today, without >> telling customers: "turn off protocol , because we can't >> deliver your packets". > > ECMP of LISP flows is an optimization that only matters when there > is a large amount of LISP traffic, right? ECMP _and_ LAG. But, in short, you're correct. However, given the dominant link speed deployed in today's networks is 10G, (which are then lashed together in N x 10G LAG and/or ECMP paths), then we clearly don't want anything near that size of single flows on these links otherwise this will have a detrimental effect on the performance of other "well-behaved" traffic that is being evenly spread over parallel links. > Do you think there is a reasonable chance that LISP would be widely- > enough to deployed to require this optimization in less than 3-to-5 > years? My crystal ball is out-of-service. In other words, that's difficult to say, given that LISP is currently pursuing a "Experimental" track. However, assuming the experiment is successful, then it's pretty safe to assume folks would want to quickly turnaround (with the methods & protocols already developed and tested during the Experiment) and turn that straight into a production service. So, IMO, it's best if we try to get this "good enough" from the beginning and not hamper its deployment by requiring networks to adapt before LISP, for example, could really take off (at least, in the short-term). Furthermore, given the LISP folks believe this is the first "iteration" of LISP, there may be 'natural' points in the LISP evolution path (for example, to support better mapping functions) where it makes sense to consider evolving the encapsulation (for example, to support flow-labels instead of UDP encaps), as well. I would argue, though, to get to those 'natural' points people will need to experiment with LISP to find out what works, and doesn't work, and bring that back to the IETF community to figure when & how to evolve LISP. >> Perhaps one way to satisfy the parties in this conversation would >> be something along the following lines: >> - LISP, and other protocols that wish to use tunneling, adopt UDP- >> lite (or UDP w/ 0 checksums) as a MUST for near-term deployment; >> - LISP, and other protocols that wish to use tunneling, adopt IP-in- >> IPv6 tunneling with a flow-label required in the outer IPv6 header >> as a "SHOULD" for medium- to long-term deployments. >> ... assuming vendors successfully adopt the IPv6 flow-label as >> input-keys in their hash calculations at some point in the future, >> we come back and deprecate the UDP/IPv6 tunnel method and elevate >> IP-in-IPv6 w/ flow-labels to a MUST. > > I would agree to this statement if one of two things were to > happen: (1) we were to remove "(or UDP w/0 checksums) -- making UDP- > Lite a MUST in the near term", or (2) we were to satisfy ourselves > that using zero checksums will not represent an operational problem > for LISP, or for other applications that need to co-habitate with > LISP, and we were to add a normative dependency on a document (like > Marshall's, with edits) that would allow the use of UDP w/0 > checksums over IPv6 in some cases, with LISP being an example of a > case where this was appropriate. Based on my conservations with several vendors, flow-based load- balancing over LAG/ECMP paths is currently NOT accounting for the following in their input-keys to LAG/ECMP hash algorithms: 1) IPv6 flow-label; or, 2) UDP-lite (since, UDP-lite uses a different protocol ID [137] compared to standard UDP [17]). In other words, if routers see UDP- lite (Protocol ID: 137), the router will revert back to just using Src/ Dst IPv6 Addresses and will not have the benefit of being exposed to the finer granularity of micro-flows that are denoted by varying the Src/Dst Layer-4 (UDP-lite) ports. Therefore, I'll have to revise my original recommendation in the first bullet above that we only consider UDP with 0 checksums as the preferred short-term solution when IPv6 is being used as the outer encapsulation, (unless someone has a better idea that haven't been brought forth, yet). -shane From iljitsch@muada.com Fri Aug 7 11:21:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E568928C1CC; Fri, 7 Aug 2009 11:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGVsgXgCWGP7; Fri, 7 Aug 2009 11:21:25 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id EEF3128C19E; Fri, 7 Aug 2009 11:21:24 -0700 (PDT) Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n77IKucH068004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 20:20:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <6B3CD48F-72BF-48E3-800B-5BC5AD46485C@muada.com> From: Iljitsch van Beijnum To: Shane Amante In-Reply-To: <5E383B58-3352-43F2-8903-22F8ECE7C57A@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 20:21:15 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <5E383B58-3352-43F2-8903-22F8ECE7C57A@castlepoint.net> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 18:21:26 -0000 Shane, thanks for infusing this discussion with some data. On 7 aug 2009, at 20:05, Shane Amante wrote: > Therefore, I'll have to revise my original recommendation in the > first bullet above that we only consider UDP with 0 checksums as the > preferred short-term solution when IPv6 is being used as the outer > encapsulation, I don't see that. Currently, there isn't that much IPv6 traffic in the first place, and certainly not between the same source/destination addresses. So the lack of a fine-grained optimal solution to the load balancing issue is not a problem in practice. This affords us the relative luxury of being able to ignore current problems in implementations and do the right thing, rather than be forced to do something ugly and difficult (that would be UDP with no checksum). And if we were to consider an ugly solution, making LISP use several IPv6 addresses per ITR/ETR would be a better solution. From shane@castlepoint.net Fri Aug 7 11:43:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B013A6A1D; Fri, 7 Aug 2009 11:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7-aZ8kAlO0D; Fri, 7 Aug 2009 11:43:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 3FC123A6AC9; Fri, 7 Aug 2009 11:43:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id AEBFD2684EA; Fri, 7 Aug 2009 12:43:30 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 07 Aug 2009 12:43:30 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=65097; data-bytes=0 Message-Id: From: Shane Amante To: Iljitsch van Beijnum In-Reply-To: <6B3CD48F-72BF-48E3-800B-5BC5AD46485C@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 12:43:27 -0600 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <5E383B58-3352-43F2-8903-22F8ECE7C57A@castlepoint.net> <6B3CD48F-72BF-48E3-800B-5BC5AD46485C@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 18:43:28 -0000 On Aug 7, 2009, at 12:21 MDT, Iljitsch van Beijnum wrote: > Shane, thanks for infusing this discussion with some data. > > On 7 aug 2009, at 20:05, Shane Amante wrote: > >> Therefore, I'll have to revise my original recommendation in the >> first bullet above that we only consider UDP with 0 checksums as >> the preferred short-term solution when IPv6 is being used as the >> outer encapsulation, > > I don't see that. Currently, there isn't that much IPv6 traffic in > the first place, and certainly not between the same source/ > destination addresses. So the lack of a fine-grained optimal > solution to the load balancing issue is not a problem in practice. > This affords us the relative luxury of being able to ignore current > problems in implementations and do the right thing, rather than be > forced to do something ugly and difficult (that would be UDP with no > checksum). In that case, I guess we'll have to agree to disagree and in doing so, I'd like to take the liberty of quoting Vince Fuller's message to this list back on 8/4/2009, where he says it better than I could: ---snip--- > Current operational reality is that the installed base of transit routers > on the Internet uses a hash of source/dest addres/port to split traffic > across LAGs so LISP uses an encapsulation that is compatible with that > reality. > > Specifying some alternate reality and hoping that the operational world will > modify its behavior to match doesn't seem very practical, particularly since > one of LISP's virtues is that it requires no changes to the transit routing > system. ---snip--- -shane From christopher.morrow@gmail.com Fri Aug 7 12:00:12 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3331B3A6FBD; Fri, 7 Aug 2009 12:00:12 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf3s7WnAO1UC; Fri, 7 Aug 2009 12:00:10 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 644EB3A67E5; Fri, 7 Aug 2009 11:59:40 -0700 (PDT) Received: by qyk41 with SMTP id 41so1767750qyk.29 for ; Fri, 07 Aug 2009 11:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Eb5c15L8emKkaP/dhupjdV/I7cR3YfmUeLtOLsW3snk=; b=nuP4GLVcipnAltU2tYq6WLh9QfnQd30KGGWrwzVeQMnsxLAmX8l+A8w4vB+G6GzQ6H 39NCZnGdfJgE+YlEeg3H2ghmy8zrBoGrGltJzD5XgrGEw2+dJAjkLOLJiqBQKfSNw8Ke cY7OprZRJNRavK7toDehBRLRZ0s9vm9hGjiZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OYTLxfwPduKkos4HCjlF1TqTrCrP9jqX/k5L0SPpnmvWwgOi479z39IaLFpBz3saAP yjla5kN8EpwLF9X6Iz9GFwuKjAZ9gk5zBVCYYSopmgeJQWObWFI/a8ddJi76kSHsOe8X oAPF+G3BSy8jpBVc20UiqfN2iBpmuOeMjbHkA= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.2.213 with SMTP id 21mr1436673qak.160.1249671581464; Fri, 07 Aug 2009 11:59:41 -0700 (PDT) In-Reply-To: References: <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> Date: Fri, 7 Aug 2009 14:59:41 -0400 X-Google-Sender-Auth: 0c95e81d2636127e Message-ID: <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> From: Christopher Morrow To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 19:00:12 -0000 On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wasserman wrote= : > > On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote: >>> >> >> This I don't recall at all... I think part of my question is we (as a >> group) are assuming that the reasons for requiring ipv6 udp checksums >> as stated +10 years ago are still valid, I don't see data supporting >> that fact. > > There are some classic papers on this topic. =A0The most recent I could f= ind > is from 2000: If by 'classic' you mean 'not relevant to today's networking technologies', sure. > http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm This study captured data on: 1) a web crawl server on a 10mb hub 2) a dorm on a broadcast 10base2 network 3) 2 locations that don't give enough information about the connections/tech used The dataset analyzed is not relevant to today's networking connectivity or technologies. Looking very quickly at a small set of data I have access to (servers serving web content to the internet users): 32,945,810,591 packets received, 0 dropped due to bad checksum (ip header checksum) 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no checksum (udp datagram stats) (collected from some unix hosts, via netstat -s or netstat -s -p udp output= ) Given this set of data I don't think that having a checksum matters for UDP or IP-header on today's internet, since there are zero errors out of ~34B packets. -chris > In a quick re-read of this paper, I didn't see anything that is obviously > dated about it. =A0So, I'd assume its error rates and analysis are still > pertinent, unless there is a more recent study that says otherwise. > > Margaret > > > > From jnc@mercury.lcs.mit.edu Fri Aug 7 12:31:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2ADB3A69D6; Fri, 7 Aug 2009 12:31:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE9b4nvFkiwK; Fri, 7 Aug 2009 12:31:09 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E2B273A6971; Fri, 7 Aug 2009 12:31:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3BD9C6BE5C1; Fri, 7 Aug 2009 15:31:11 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> Date: Fri, 7 Aug 2009 15:31:11 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 19:31:09 -0000 > From: Francis Dupont > the O UDP checksum proposal obsoletes all the today deployed nodes > which check them (so all hosts I know and perhaps a lot of routers too) OK, so what are the other options for encapsulating a packet in a IPv6 packet? I'm told by some people that UDP-Lite isn't a standard yet? Or is it? (It seems to have a protocol number issued?) Does UDP-Lite work through NAT boxes? (LISP has a mobile-node mode, which we would like to see work through NAT boxes, so any proposed alternative solution has to work through NAT boxes too.) Other ideas? Also, hosts aren't an issue - and in fact it's a _feature_ that hosts will discard any LISP packets they see (for having bad checksums). > From: Shane Amante > this is the first "iteration" of LISP, there may be 'natural' points in > the LISP evolution path ... where it makes sense to consider evolving > the encapsulation Excellent point. We have indeed already considered deploying other encapsulations, e.g. for use over MPLS. > From: Iljitsch van Beijnum > there isn't that much IPv6 traffic in the first place ... > So the lack of a fine-grained optimal solution to the load balancing > issue is not a problem in practice. Is it your prediction for the near (i.e. 2-3 year) future that this level of traffic will continue to be the case, operationally? Noel From tme@americafree.tv Fri Aug 7 12:43:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B1728C21C; Fri, 7 Aug 2009 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNzfqepsoP3S; Fri, 7 Aug 2009 12:43:00 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D004D28C20A; Fri, 7 Aug 2009 12:42:59 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8854F46D209B; Fri, 7 Aug 2009 15:42:50 -0400 (EDT) Message-Id: <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> From: Marshall Eubanks To: Christopher Morrow In-Reply-To: <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 15:42:48 -0400 References: <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 19:43:01 -0000 On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote: > On Wed, Aug 5, 2009 at 5:07 PM, Margaret > Wasserman wrote: >> >> On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote: >>>> >>> >>> This I don't recall at all... I think part of my question is we >>> (as a >>> group) are assuming that the reasons for requiring ipv6 udp >>> checksums >>> as stated +10 years ago are still valid, I don't see data supporting >>> that fact. >> >> There are some classic papers on this topic. The most recent I >> could find >> is from 2000: > > If by 'classic' you mean 'not relevant to today's networking > technologies', sure. > >> http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm > > This study captured data on: > > 1) a web crawl server on a 10mb hub > 2) a dorm on a broadcast 10base2 network > 3) 2 locations that don't give enough information about the > connections/tech used > > The dataset analyzed is not relevant to today's networking > connectivity or technologies. Looking very quickly at a small set of > data I have access to (servers serving web content to the internet > users): > > 32,945,810,591 packets received, 0 dropped due to bad checksum (ip > header checksum) > > 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no > checksum (udp datagram stats) Just polling the routers here, I see a similar scenario, e.g., 4,166,900,871 packets 0 dropped due to bad checksum However, this is over good clean fiber links. What I would worry about are RF links, such as 802.11 or P2P microwaves. These generally have link layer redundancy / checksums, etc., which I think are pretty good at detecting corrupted packets, but it might not be wise to rely on that. I wonder if we could dig up similar numbers for the IETF 802.11 network. I will make inquiries. Regards Marshall > > > (collected from some unix hosts, via netstat -s or netstat -s -p udp > output) > > Given this set of data I don't think that having a checksum matters > for UDP or IP-header on today's internet, since there are zero errors > out of ~34B packets. > > -chris > >> In a quick re-read of this paper, I didn't see anything that is >> obviously >> dated about it. So, I'd assume its error rates and analysis are >> still >> pertinent, unless there is a more recent study that says otherwise. >> >> Margaret >> >> >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From dino@cisco.com Fri Aug 7 12:46:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBD13A6EC1; Fri, 7 Aug 2009 12:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ6ylVyVzUC0; Fri, 7 Aug 2009 12:46:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A08183A69CF; Fri, 7 Aug 2009 12:46:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANkhfEqrR7O6/2dsb2JhbAC4DYgrkBcFhBaBUQ X-IronPort-AV: E=Sophos;i="4.43,343,1246838400"; d="scan'208";a="362839386" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2009 19:46:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n77Jkb3Z020558; Fri, 7 Aug 2009 12:46:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n77JkbtZ026190; Fri, 7 Aug 2009 19:46:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:46:36 -0700 Received: from [192.168.1.14] ([10.21.127.105]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:46:36 -0700 Message-Id: <63F4A212-90E2-47AB-8415-C2397C5DE51B@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 12:46:35 -0700 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 19:46:36.0489 (UTC) FILETIME=[C61ED390:01CA1797] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=599; t=1249674397; x=1250538397; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=pQKhUOgbxSDZSExWjx59n8lg1aSkTLesAGbU7H6oxVo=; b=P+5We5eqHnkwnm7EpcmRtLsmTB0PMg+WNwWZo1PZ0onTg9wgOEeKW4WljH oy4/BQLxTftSnVfsVcPovImow3kmzhGfu55VzEYOLgoYvD4z8j5Nxpm4sTCn LxlzMCDGMW; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ipv6@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 19:46:34 -0000 Not sensible enough. Dino On Aug 4, 2009, at 7:58 AM, Margaret Wasserman wrote: > > On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote: >> >>> What I'm saying is that *if* UDP us used, it needs to be used >>> according to the RFCs that capture the IETF consensus on their >>> use, or the IETF consensus must be revised. >> >> And what we are are saying is to be practical (and sensible). > > Well, what *I* am saying is that UDP-Lite was designed to offer a > practical and sensible alternative for exactly these situations. > Why won't it work for LISP? > > Margaret From dino@cisco.com Fri Aug 7 12:47:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2A228C23F for ; Fri, 7 Aug 2009 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lo-wlTFurRq for ; Fri, 7 Aug 2009 12:47:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1CC2128C251 for ; Fri, 7 Aug 2009 12:47:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANkhfEqrR7PD/2dsb2JhbAC4DYgrkBcFhBaBUYg8 X-IronPort-AV: E=Sophos;i="4.43,343,1246838400"; d="scan'208";a="362839808" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2009 19:47:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n77JlLOX023691; Fri, 7 Aug 2009 12:47:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n77JlLti026763; Fri, 7 Aug 2009 19:47:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:47:21 -0700 Received: from [192.168.1.14] ([10.21.127.105]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 12:47:20 -0700 Message-Id: <4AA28E27-1132-4C12-9FBE-898E9EB6DE90@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 12:47:21 -0700 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 19:47:20.0738 (UTC) FILETIME=[E07EB020:01CA1797] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=97; t=1249674441; x=1250538441; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=skKCe6uhTA4WhoLxN8Cudo5WM8jrI96FkKa1/YWzXLE=; b=dL0at3RHsXYiCbPYiSzzKHbn15DGIEy5ZLH4M04o8zwEGO/SxGq2VXHWYa lr3QEjP6VoS/TTyM3FiCBIqQr1Yhhsr5+7g+3kH/dJaGF1GSn++/zsaj5FF4 MNeWVmmw2K; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 19:47:18 -0000 > 2) Document why you'd use UDP, not IPIP or udp-light. This is already in the spec. Dino From iljitsch@muada.com Fri Aug 7 13:05:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCD23A6932; Fri, 7 Aug 2009 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu0mG05l0Xx0; Fri, 7 Aug 2009 13:05:39 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8E13A67CF; Fri, 7 Aug 2009 13:05:39 -0700 (PDT) Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n77K5GNt068734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 22:05:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Noel Chiappa In-Reply-To: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 22:05:35 +0200 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 20:05:40 -0000 On 7 aug 2009, at 21:31, Noel Chiappa wrote: > I'm told by some people that UDP-Lite isn't a standard yet? Or is > it? (It > seems to have a protocol number issued?) http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml Protocol 136, RFC 3828. > Does UDP-Lite work through NAT > boxes? (LISP has a mobile-node mode, which we would like to see work > through > NAT boxes, so any proposed alternative solution has to work through > NAT boxes > too.) For IPv6? >> there isn't that much IPv6 traffic in the first place ... >> So the lack of a fine-grained optimal solution to the load balancing >> issue is not a problem in practice. > Is it your prediction for the near (i.e. 2-3 year) future that this > level of > traffic will continue to be the case, operationally? The amount of traffic where lack of load balancing granularity beyond the 3-tuple starts to hurt is in the order of a quarter of the link speed (could be 25% of 100 Mbps to 40 Gbps). So if we can now fill in the number of users that are encapsulated together between an ITR and an ETR (could be hundreds to hundreds of thousands) and the amount of traffic that is IPv6 (currently 0.2% at AMS-IX, perhaps 10% in the near future or even 50% or more) then we can see how big the problem really is. It's not impossible to arrive at numbers where the load balancing starts being problematic with only the 3-tuple but to get there within a year or three (or even five) you have to assume radical IPv6 and LISP uptake coupled with either massive ITRs/ETRs or miniscule links. From christopher.morrow@gmail.com Fri Aug 7 13:06:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DA23A6FA5; Fri, 7 Aug 2009 13:06:16 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUBowaodwzwh; Fri, 7 Aug 2009 13:06:15 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 2046F3A67E7; Fri, 7 Aug 2009 13:06:15 -0700 (PDT) Received: by qyk41 with SMTP id 41so1804252qyk.29 for ; Fri, 07 Aug 2009 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=4IfbMOSwBWxGMdFtxCX8VtDyThDz/ocpuRGQGLoDRKw=; b=i6jUZ1XVrXR/I2kQoJq+iEejD4iWIkhGVWBXsP5tVpUdjZVrEVehVcWfwtBwaq1sas CLkgVjZKSDQwQrxvW+WVhDYUmGFHF1wCR9oeocSlimpD4CxVjOAN+SOoP3tnfPIxevcw 0AcQLJtyJbCZl6AXGPDsJf7TSCMtJZcEDpdNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=A18F3mPO4xRakal3R3QxgDjP2dvUlnEjAFkesq3cBlBLPx7mW3FCoLdtO8C/0nxu4t emGpQDrOqKRfLIbzYHOELzUXfZrtcAuYG+frjB8UAUYO5UqjPOJofqm3qRBCLvwL99QE mdAq/VZZW/5lJlnZwRnr73/p7UnLuSyg1qjco= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.2.80 with SMTP id 16mr1526191qai.90.1249675576452; Fri, 07 Aug 2009 13:06:16 -0700 (PDT) In-Reply-To: <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> References: <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> Date: Fri, 7 Aug 2009 16:06:16 -0400 X-Google-Sender-Auth: 829dea9ba43ed111 Message-ID: <75cb24520908071306x266d635bmf4377355affce2a6@mail.gmail.com> From: Christopher Morrow To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 20:06:16 -0000 On Fri, Aug 7, 2009 at 3:42 PM, Marshall Eubanks wrote: > > On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote: > >> On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wasserman >> wrote: >>> >>> On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote: >>>>> >>>> >>>> This I don't recall at all... I think part of my question is we (as a >>>> group) are assuming that the reasons for requiring ipv6 udp checksums >>>> as stated +10 years ago are still valid, I don't see data supporting >>>> that fact. >>> >>> There are some classic papers on this topic. =A0The most recent I could >>> find >>> is from 2000: >> >> If by 'classic' you mean 'not relevant to today's networking >> technologies', sure. >> >>> http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm >> >> This study captured data on: >> >> 1) a web crawl server on a 10mb hub >> 2) a dorm on a broadcast 10base2 network >> 3) 2 locations that don't give enough information about the >> connections/tech used >> >> The dataset analyzed is not relevant to today's networking >> connectivity or technologies. Looking very quickly at a small set of >> data I have access to (servers serving web content to the internet >> users): >> >> 32,945,810,591 packets received, 0 dropped due to bad checksum (ip >> header checksum) >> >> 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no >> checksum (udp datagram stats) > > Just polling the routers here, I see a similar scenario, e.g., > > 4,166,900,871 packets 0 dropped due to bad checksum neat! (I'm also going to see if I can get some stats from a wider set of hosts, but....) > However, this is over good clean fiber links. What I would worry about ar= e > RF links, such as 802.11 or P2P microwaves. These generally have link lay= er > redundancy / checksums, etc., which I think are pretty good at detecting > corrupted packets, > > it might not be wise to rely on that. > > I wonder if we could dig up similar numbers for the IETF 802.11 network. = I > will make inquiries. > > Regards > Marshall > > >> >> >> (collected from some unix hosts, via netstat -s or netstat -s -p udp >> output) >> >> Given this set of data I don't think that having a checksum matters >> for UDP or IP-header on today's internet, since there are zero errors >> out of ~34B packets. >> >> -chris >> >>> In a quick re-read of this paper, I didn't see anything that is obvious= ly >>> dated about it. =A0So, I'd assume its error rates and analysis are stil= l >>> pertinent, unless there is a more recent study that says otherwise. >>> >>> Margaret >>> >>> >>> >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From iljitsch@muada.com Fri Aug 7 13:11:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698D03A6E3A; Fri, 7 Aug 2009 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFldGsLoAGLz; Fri, 7 Aug 2009 13:11:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F2E003A6943; Fri, 7 Aug 2009 13:11:01 -0700 (PDT) Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n77KAWvL068773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Aug 2009 22:10:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <31E5414C-347F-4D47-AED8-7866FD28C0EC@muada.com> From: Iljitsch van Beijnum To: Shane Amante In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Aug 2009 22:10:52 +0200 References: <81FB17E4-9126-466A-9BC5-1CDE97ED3946@muada.com> <375BAB1F-B29E-476A-92E0-B0CDB5B55723@castlepoint.net> <7CE2AC34-2659-4947-8EE9-B4ECD4A32F39@muada.com> <4A784EEF.2020405@joelhalpern.com> <4A78B51C.2010902@gmail.com> <4A78F3C6.4020602@joelhalpern.com> <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <5E383B58-3352-43F2-8903-22F8ECE7C57A@castlepoint.net> <6B3CD48F-72BF-48E3-800B-5BC5AD46485C@muada.com> X-Mailer: Apple Mail (2.936) Cc: IAB , 6man 6man , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Aug 2009 20:11:03 -0000 CCing the IAB because I think we are reaching a slippery architectural slope. Hopefully they can help us out. On 7 aug 2009, at 20:43, Shane Amante wrote: >>> Therefore, I'll have to revise my original recommendation in the >>> first bullet above that we only consider UDP with 0 checksums as >>> the preferred short-term solution when IPv6 is being used as the >>> outer encapsulation, >> I don't see that. Currently, there isn't that much IPv6 traffic in >> the first place, and certainly not between the same source/ >> destination addresses. So the lack of a fine-grained optimal >> solution to the load balancing issue is not a problem in practice. >> This affords us the relative luxury of being able to ignore current >> problems in implementations and do the right thing, rather than be >> forced to do something ugly and difficult (that would be UDP with >> no checksum). > In that case, I guess we'll have to agree to disagree Well, we still either have UDP encapsulation with a 0 checksum for LISP over IPv6 or not. > and in doing so, I'd like to take the liberty of quoting Vince > Fuller's message to this list back on 8/4/2009, where he says it > better than I could: > ---snip--- > > Current operational reality is that the installed base of transit > routers > > on the Internet uses a hash of source/dest addres/port to split > traffic > > across LAGs so LISP uses an encapsulation that is compatible with > that > > reality. > > > > Specifying some alternate reality and hoping that the operational > world will > > modify its behavior to match doesn't seem very practical, > particularly since > > one of LISP's virtues is that it requires no changes to the > transit routing > > system. > ---snip--- The problem with adopting that logic and adopting a UDP header for LISP even though that would require breaking the IPv6 spec just because router vendors haven't gotten around to implementing ECMP based on the flow label is that it cements us into a TCP/UDP view of the world with IPv6 just like NATs did for IPv4. In my opinion, the possible short term pain of less than optimal load balancing in a few places with high IPv6 LISP traffic is worth it if that allows us to proceed in an architecturally clean way. From christopher.morrow@gmail.com Fri Aug 7 18:22:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849A23A6A14; Fri, 7 Aug 2009 18:22:51 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro5R94wCJBk1; Fri, 7 Aug 2009 18:22:50 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 939A23A6A05; Fri, 7 Aug 2009 18:22:50 -0700 (PDT) Received: by qyk41 with SMTP id 41so1938319qyk.29 for ; Fri, 07 Aug 2009 18:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e7Or6gap2sUc9Fa3RIa+Wrjbce17y9SZIsQfW5jqCz4=; b=DBS3D11RwiuyweEgjbkbHDF/byfCUldNFc4TRszgBaajPpE/ToGJ4lC9ghoHO/NC2n ctlEcmrKsYHESal3Xvj6f2zHT6l1t2SHSVwZR9qXPcA3mTIne8znRB8S5muzwmMQ5dAL pEemaOEkq1ewEPxQ5UJE3nGUGLHbp91521+2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tvEYdIXrEnYDlb2oOHYEL9BU2R9XYtJAT9DVp0mv9M2ZKRYqLe58Ri6L1RTarMoCuP dWmdmQn/jSH++8JLqQw4ai8Led+5uykLURy/oib1VhkNnuUEcZX3Q6C/pEaHp9OyW4aB BrVE0HrP9uttotyAhWG81/DX7HHAD4SERISfg= MIME-Version: 1.0 Received: by 10.224.20.17 with SMTP id d17mr1631148qab.204.1249694571420; Fri, 07 Aug 2009 18:22:51 -0700 (PDT) In-Reply-To: <20090808.022204.92569755.he@uninett.no> References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> Date: Fri, 7 Aug 2009 21:22:51 -0400 Message-ID: <75cb24520908071822p3c196159p72f0ec395c64ff71@mail.gmail.com> From: Christopher Morrow To: Havard Eidnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 01:22:51 -0000 On Fri, Aug 7, 2009 at 8:22 PM, Havard Eidnes wrote: >> =A0 =A0 > the O UDP checksum proposal obsoletes all the today deployed n= odes >> =A0 =A0 > which check them (so all hosts I know and perhaps a lot of rou= ters too) >> >> OK, so what are the other options for encapsulating a packet in a IPv6 >> packet? > > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? > > Let's look at this another way? =A0As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. > > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. warning this discssion morphed from a 'what should ipv6/ipv4 translators do..' discssion. While a non-lisp node receiving a LISP udp/0 packet dropping it seems fine to me, a translator dropping a udp/0|null-sum packet instead of translating it properly or telling the source-system: "oops, something bad happened" is unacceptable (in my mind). > In practical terms, only LISP encap/decap devices would need to > be modified to accept 0 UDP packets under some specific rule / > circumstance, as an exception to the general rule. See above comment. I really think that in the wider context the udp-checksum decision for ipv6 needs to be revisited. There are more than a few cases where the current state of inconsistency needs to be trued up. -chris From jnc@mercury.lcs.mit.edu Fri Aug 7 20:13:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1B33A67E6; Fri, 7 Aug 2009 20:13:29 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77sGksIAmAxC; Fri, 7 Aug 2009 20:13:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id BCFCC3A67A8; Fri, 7 Aug 2009 20:13:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BB9726BE5CA; Fri, 7 Aug 2009 23:13:30 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> Date: Fri, 7 Aug 2009 23:13:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 03:13:29 -0000 > From: Christopher Morrow > While a non-lisp node receiving a LISP udp/0 packet dropping it seems > fine to me, a translator dropping a udp/0|null-sum packet instead of > translating it properly or telling the source-system: "oops, something > bad happened" is unacceptable (in my mind). Ow; now you're making my head hurt. I don't think LISP was ever intended to work in the circumstance where an IPv[46] xTR was talking directly to an IPv[64] (i.e. the opposite of the other one) xTR, via a IPv[4-6] translator box - just like we don't expect IPv4 routers to talk to IPv6 routers through an IPv[4-6] translator box. So I'm not sure we need to worry about that case either? Or do we need that case to work? Are there really going to be operational cases _during the term of the LISP experimental phase_ with IPv4-only xTRs needing to talk to IPv6-only xTRs? (That is of course separate from the case where a IPv6-only xTR wants to talk to another IPv6-only xTR, and there is no direct v6-native path between them - it was at that point that my head started to hurt....) Noel From christopher.morrow@gmail.com Fri Aug 7 22:12:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA8B3A68D3; Fri, 7 Aug 2009 22:12:23 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+ALTikTu3ND; Fri, 7 Aug 2009 22:12:23 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id E2A0E3A67A2; Fri, 7 Aug 2009 22:12:22 -0700 (PDT) Received: by qyk41 with SMTP id 41so2000512qyk.29 for ; Fri, 07 Aug 2009 22:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=z6fTzzAJXUdmji/QYo7JwUnMMCyyh6dJ1MuEHUOmQuI=; b=jucRnANV218zLw9O31Z52Po2SlcxcSTruhCLoyDRlntUvcGJ2QN9QB7oiaBEI0WHZo R+6WSnkBMwB/h3h/jgIDRJ+BVif9L9TvZkx5/YnaMPOQwKkHp46rf0uMyr/nlFj9FJwj QYylVdRlitF9CPfUxUtZz+CeY4OAHlK0NdNP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sit5FscpDcOrk5ltgFXA53/yJEUXdfYTbziAR8DZv4mBINWJEddGPNAY2tgy+i3D2k pmRn6cKXhja4qQe8e1YxaNTw7fvwd7UELLQhuekxA6oQRmv+kT5oR9qy5jKJ2NnHdN31 c5Vde3425bNPzjrCNSBpjs3Ej3DuSMuDyPe34= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.2.80 with SMTP id 16mr1760777qai.90.1249708344170; Fri, 07 Aug 2009 22:12:24 -0700 (PDT) In-Reply-To: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> References: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> Date: Sat, 8 Aug 2009 01:12:24 -0400 X-Google-Sender-Auth: e452d11acd2adeaf Message-ID: <75cb24520908072212u4f9c6218i208a7be2a3da386f@mail.gmail.com> From: Christopher Morrow To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 05:12:24 -0000 On Fri, Aug 7, 2009 at 11:13 PM, Noel Chiappa wrot= e: > =A0 =A0> From: Christopher Morrow > > =A0 =A0> While a non-lisp node receiving a LISP udp/0 packet dropping it = seems > =A0 =A0> fine to me, a translator dropping a udp/0|null-sum packet instea= d of > =A0 =A0> translating it properly or telling the source-system: "oops, som= ething > =A0 =A0> bad happened" is unacceptable (in my mind). > > Ow; now you're making my head hurt. sorry about that. > I don't think LISP was ever intended to work in the circumstance where an > IPv[46] xTR was talking directly to an IPv[64] (i.e. the opposite of the > other one) xTR, via a IPv[4-6] translator box - just like we don't expect > IPv4 routers to talk to IPv6 routers through an IPv[4-6] translator box. Nope, perhaps not. The original version of this discussion started on ipv6@, and was about what to do if/when a 4to6 (say a nat64 device) translator gets a packet that would match the criteria in question. > So I'm not sure we need to worry about that case either? Or do we need th= at > case to work? Are there really going to be operational cases _during the = term > of the LISP experimental phase_ with IPv4-only xTRs needing to talk to > IPv6-only xTRs? > > (That is of course separate from the case where a IPv6-only xTR wants to = talk > to another IPv6-only xTR, and there is no direct v6-native path between t= hem - > it was at that point that my head started to hurt....) sorry :( -Chris From jnc@mercury.lcs.mit.edu Sat Aug 8 07:39:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE61F3A6A9C; Sat, 8 Aug 2009 07:39:39 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-mnVZ+TQTCT; Sat, 8 Aug 2009 07:39:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0E63D3A6958; Sat, 8 Aug 2009 07:39:18 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 531676BE563; Sat, 8 Aug 2009 10:39:21 -0400 (EDT) To: ipv6@ietf.org, lisp@ietf.org Message-Id: <20090808143921.531676BE563@mercury.lcs.mit.edu> Date: Sat, 8 Aug 2009 10:39:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 14:39:39 -0000 > From: Christopher Morrow > The original version of this discussion started on ipv6@, and was about > what to do if/when a 4to6 (say a nat64 device) translator gets a packet > that would match the criteria in question. Now that it's morning, and my brain is actually functioning, this is a non-issue. If LISP ever gets to production phase, the solution is trivial. An ITR can tell from the mapping for the destination EID whether the ETR(s) for that EID has/have IPv4 or IPv6 address(es) (or both). The spec can simply mandate that packets destined for an ETR with only an IPv6 address have to be emitted inside an IPv6 packet, and vice versa. So there will never be a need for translation. Arrival of a LISP packet at a translator is an error, and the translator _should_ silently drop it - a checksum error will do this nicely. I'm not sure we want to include this mandate in the experimental phase of LISP, for two reasons. First, it requires dual-stack implementations in all xTRs, which to me seems an unneccessary burden for an experiment. Second, and more important, there's still this whole issue of 'what happens if there's no direct IPv6-native path between two IPv6 xTRs'? Note that this problem exists whether we fix the translator problem using the method above, or not. Two IPv6-only xTRs may or may not have an IPv6-native path between them - if not, a tunnel will have to be arranged. (Barf.) You _cannot_ use _translation_ to fix this problem, because that would mean you have a way of mapping the entire IPv6 address space into IPv4 addresses - clearly impossible. Noel From dino@cisco.com Sat Aug 8 20:11:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461A53A6C15 for ; Sat, 8 Aug 2009 20:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+b3Mj8EQvRT for ; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 736AB3A6C02 for ; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJvbfUqrR7O6/2dsb2JhbAC2IYgrjy4FhBiKEw X-IronPort-AV: E=Sophos;i="4.43,347,1246838400"; d="scan'208";a="363523198" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2009 03:11:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n793BxfC008213; Sat, 8 Aug 2009 20:11:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n793Bxo4018170; Sun, 9 Aug 2009 03:11:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:58 -0700 Received: from [10.224.11.219] ([10.21.93.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:44 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 18:01:22 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Aug 2009 03:11:44.0411 (UTC) FILETIME=[1FB20EB0:01CA189F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1328; t=1249787519; x=1250651519; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=Nij4kbDl19Wx/kIvvLHAod5ZnYIh+EszQOg1e5P+qoU=; b=tbfhYWZ9M5sc7kdvDhPGjPyfE0Byz2fxhupAN0xrQE+NhjEGfPy8a81UGl 2ctLQncKcd8x/NhLqPgC6IbE/+m4No4UVQ5XKXOnbv9RX83DX9YIndF48UmU Sm4qVYCtXh; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 03:11:58 -0000 > Here are options as I see them: > > 1) We can use 0 checksums with UDP, adding a normative reference to a > standards track document updating RFC 2460. Our spec will block > behind this standards track document and will move no faster than it > does. If the IETF chooses to go a different route, we will be faced > with having to make incompatible changes to LISP late in the process. > If that happens, individuals can come to the personal conclusion that > they are no longer interested in spending effort on the IETF LISP > spec, but they will not have the option of publishing a LISP spec > through the IETF that disagrees with IETF consensus. I vote for this. So we can use the same encapsulation for all 4 combinations and keep a clean design thank you. > 2) We can change LISP to use UDP-light. Doesn't solve the problem. It's more work that doesn't buy you anything. Plus you want full UDP checksums for control packets. Right now we use the same header encapsulation for destination port 4341 and 4342. This keeps it clean so you can use common parsers. > 3) We can make more significant changes to the LISP encapsulation. We are doing all this for an experimental protocol? Folks, please believe in data-link CRCs. They do error correction to 10^-13 these days. Dino From dino@cisco.com Sat Aug 8 20:11:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558F73A6C02 for ; Sat, 8 Aug 2009 20:11:58 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA8PqOoVl+KP for ; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A596B3A6BBC for ; Sat, 8 Aug 2009 20:11:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJvbfUqrR7O6/2dsb2JhbAC2IYgrjy4FhBiKEw X-IronPort-AV: E=Sophos;i="4.43,347,1246838400"; d="scan'208";a="363523192" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2009 03:11:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n793BwxL008205; Sat, 8 Aug 2009 20:11:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n793BvwH016153; Sun, 9 Aug 2009 03:11:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:57 -0700 Received: from [10.224.11.219] ([10.21.93.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:39 -0700 Message-Id: <82C32A62-89FD-4F43-BACC-1C9C9D4BDEDF@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 17:29:42 -0700 References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Aug 2009 03:11:40.0005 (UTC) FILETIME=[1D11C150:01CA189F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2899; t=1249787518; x=1250651518; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Outer=20header=20damage=20[Re= 3A=20=20Flow=20label=20redux] |Sender:=20; bh=6rBLRMavrHt9FnVuq1gMtqbuPGWH4P3iwFR7KiRvCio=; b=eY+BPT4v+snNTI0FnvUAVXsH5Imn6mb8ZTcf+TdYeWlKHmrw82+piT8flR ei3S+aYOHAbfK6431khzk2FNYzeBtXRM9Vw4ldvIjG+wqV0o5ShpKelFpXlG kGaqNFmsOy; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 03:11:58 -0000 > Speaking as an individual for the moment: > >>>>>> "Noel" == Noel Chiappa writes: > Noel> - The packet may arrive with a damaged source address. This > Noel> may cause a bogus 'partner ITR' entry to be created > Noel> (e.g. for the echo nonce entry), but I can't think of any > Noel> real problems that will happen in this case. > > > I'm sending this message, mainly to indicate that the problem of outer > header corruption is one that requires real technical thought and that > has non-obvious consequences. Are you worried the header is going to be corrupt and the link layer will not catch it? > It may well be that we can design a LISP for which the possibility of > outer header corruption is acceptable and for which we can convince > ourselves of this fact. Are we talking about security or bit-errors? Let's be real clear here. > However it's fairly easy for me to illustrate this requires actual > work and thought. > > Under the current lisp-03 spec, an ETR receiving such a packet is > allowed to create a gleaned cache entry for the source EID in the > packet, using the outer RLOC (the corrupted source IP address) for > communication with that EID. > > Nothing in the current spec mandates that the ETR send a confirming > map-request, and I believe the default TTL is rather long. Yes the spec does say that. > Ignore for the moment that by the time we get done discussing > security, the behavior may be somewhat different:-) So the only way this would happen is if there was a bit-error from the last-hop that forwarded the packet to the ETR router. Is that what yo want to focus the discussion on? > It is clearly the case with today's LISP spec that a single corrupted > packet is permitted to disrupt communications between two lisp nodes > for a significant period of time. There is nothing in the spec that says *this is permitted*. Dino > This illustrates that it is very easy to design a protocol for which > this sort of corruption is easy. Thus, I believe that the kind of > analysis Margaret is asking for needs to be performed carefully and > fully. I for one will disregard any message claiming that outer > header corruption is not a problem if it includes the words "obvious," > "easy," is generally dismissive of the problem, or is not thoroughly > detailed. > > I want to stress that your message was a great technical contribution: > you were trying to find an easy way to dismiss a concern so we could > go onto other issues. My problem is that after spending an hour or > so looking at the current LISP spec with regard to this issue, I've > come to the conclusion that there is no such easy mechanism. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sat Aug 8 20:11:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612083A6BBC; Sat, 8 Aug 2009 20:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orcgtAP1DTLC; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6B81A3A6BEF; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJvbfUqrR7PD/2dsb2JhbAC2IYgrjy4FhBiBUYJVhW0 X-IronPort-AV: E=Sophos;i="4.43,347,1246838400"; d="scan'208";a="363523196" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2009 03:11:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n793BwEd010230; Sat, 8 Aug 2009 20:11:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n793BwpV018166; Sun, 9 Aug 2009 03:11:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:58 -0700 Received: from [10.224.11.219] ([10.21.93.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:43 -0700 Message-Id: <238B5CE8-ABFD-45D3-9E6D-BFEB6E10CE46@cisco.com> From: Dino Farinacci To: Noel Chiappa In-Reply-To: <20090808143921.531676BE563@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 17:54:41 -0700 References: <20090808143921.531676BE563@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Aug 2009 03:11:43.0849 (UTC) FILETIME=[1F5C4D90:01CA189F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2029; t=1249787518; x=1250651518; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Flow=20label=20redux |Sender:=20; bh=flpeWY007g+2efN0riv22xmQGWD4Hsm5XYtd5MzfX6s=; b=qI0pxoy0DgrpcICdBnEtrnhVLqlE6Ef1k6oMUTHhTiRhKwSI8Zxq/dHZ0B WoPuDq1yJBGn90tAvsr276DW1uoZ71/0Ad4EGSixGHgRIchKCcPHbnN2t417 w+EjBCOf/y; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 03:11:58 -0000 And what about multicast? ;-) Dino On Aug 8, 2009, at 7:39 AM, Noel Chiappa wrote: > >> From: Christopher Morrow > >> The original version of this discussion started on ipv6@, and was >> about >> what to do if/when a 4to6 (say a nat64 device) translator gets a >> packet >> that would match the criteria in question. > > Now that it's morning, and my brain is actually functioning, this is a > non-issue. If LISP ever gets to production phase, the solution is > trivial. > > An ITR can tell from the mapping for the destination EID whether the > ETR(s) > for that EID has/have IPv4 or IPv6 address(es) (or both). The spec > can simply > mandate that packets destined for an ETR with only an IPv6 address > have to be > emitted inside an IPv6 packet, and vice versa. So there will never > be a need > for translation. Arrival of a LISP packet at a translator is an > error, and the > translator _should_ silently drop it - a checksum error will do this > nicely. > > > I'm not sure we want to include this mandate in the experimental > phase of > LISP, for two reasons. First, it requires dual-stack implementations > in all > xTRs, which to me seems an unneccessary burden for an experiment. > Second, and > more important, there's still this whole issue of 'what happens if > there's no > direct IPv6-native path between two IPv6 xTRs'? > > Note that this problem exists whether we fix the translator problem > using the > method above, or not. Two IPv6-only xTRs may or may not have an IPv6- > native > path between them - if not, a tunnel will have to be arranged. > (Barf.) You > _cannot_ use _translation_ to fix this problem, because that would > mean you > have a way of mapping the entire IPv6 address space into IPv4 > addresses - > clearly impossible. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sat Aug 8 20:11:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1743A6BEF; Sat, 8 Aug 2009 20:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+tvd3x4AdZs; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 58F6B3A6BBD; Sat, 8 Aug 2009 20:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJvbfUqrR7MV/2dsb2JhbAC2IYgrjy4FhBiBUYhC X-IronPort-AV: E=Sophos;i="4.43,347,1246838400"; d="scan'208";a="363523194" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2009 03:11:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n793Bw39028894; Sat, 8 Aug 2009 20:11:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n793Bwt1016156; Sun, 9 Aug 2009 03:11:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:57 -0700 Received: from [10.224.11.219] ([10.21.93.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 20:11:41 -0700 Message-Id: <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 17:34:00 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 09 Aug 2009 03:11:41.0568 (UTC) FILETIME=[1E004000:01CA189F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=694; t=1249787518; x=1250651518; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=c9x40fJGIUcFFqErxk+5wseY2kzhMSxuTSjujLHoajw=; b=YKDyYKKFzujyfKqJwWWVKQtVdNyaEFtZs4z6WiKVzTCVSBDLKesCEXevf4 XGnbZ4ew1CZ67VuiWQC2bFeFaUmsbIcHvVc4dUy1RhrCqSLTP/Iu0RC+jTcV J4eeq55AKBY3GGAF4LPYjrxTSGe+KL280N34MfqJEY/F7vqEex7TQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 03:11:58 -0000 > > I suggest that your draft > > 1) Indicate whether receivers should be specially configured to accept > 0 checsums or whether all stacks should accept 0 checksums. The spec says ETRs MUST ignore the UDP checksum field. This is what the LISP authors intended and has been implemented this way. The spec says ITRs MUST set the UDP checksum field to 0. Dino > 2) Adapt her questions as questions that IETF specs considering this > exception need to answer to make sure that their protocol will work > correctly in this mode. > > --Sam > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From christopher.morrow@gmail.com Sun Aug 9 19:29:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9F63A6824; Sun, 9 Aug 2009 19:29:53 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC54rP33pNDa; Sun, 9 Aug 2009 19:29:52 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 3A4423A67BD; Sun, 9 Aug 2009 19:29:52 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1062930qwi.31 for ; Sun, 09 Aug 2009 19:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wtWwvIJVdoe52NRNUQJSA0Mv252m9+vOGId5LBkOlv0=; b=hnFKLbRnwG6UkW0rBtmZma/xxFs1+BD5kbDozpPm+vlIj8tEqoH7hJ4e4TQs64Y24z nje5NAN45L7mfHyOAngt+94Hksz1xVNifFxhVVrMOmTqHdX4kNQhgKCkZ9TxKT1qlDgv 70VGpSDJhXqhC7Taqjv3enYmOZXC28V4raa4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QhY1JeKqVAkqTOrPfglvGbgSt4crHXCPe5Dl292zbRv5+26yF38OD+8MCHtji5l+H3 M14X2fCccwEa7Z3srGwkaQQ2O5Y0ZBJubwBfUqI+iKkwPUwItHZHn6RkPwowBUXa1rLj DZ3ZL3bNz7PftCF4RLbPN0gD7PE1Uu7fZQ1qg= MIME-Version: 1.0 Received: by 10.224.20.17 with SMTP id d17mr2742313qab.204.1249871392423; Sun, 09 Aug 2009 19:29:52 -0700 (PDT) In-Reply-To: <200908092214.n79MEHEM028385@givry.fdupont.fr> References: <27109484-9BF9-4ED9-B40D-DCB96788B074@castlepoint.net> <200908092214.n79MEHEM028385@givry.fdupont.fr> Date: Sun, 9 Aug 2009 22:29:52 -0400 Message-ID: <75cb24520908091929v60185a3dq7838c7e0118f6f5b@mail.gmail.com> From: Christopher Morrow To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 02:29:53 -0000 On Sun, Aug 9, 2009 at 6:14 PM, Francis Dupont w= rote: > =A0In your previous mail you wrote: > PS: IMHO this is an example of IPv6 misunderstanding: the solution > was developed for IPv4 and as it doesn't fit exactly into IPv6 > in place of adjusting the solution you propose to adjust IPv6. ugh... Thanks for listening to operators and device implementors providing input to the process Francis. Always nice to see that we are appreciated in this arena. -Chris From he@uninett.no Fri Aug 7 17:22:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949243A6F89; Fri, 7 Aug 2009 17:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpdzscH4tYIH; Fri, 7 Aug 2009 17:22:02 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by core3.amsl.com (Postfix) with ESMTP id A704C3A6BA3; Fri, 7 Aug 2009 17:22:02 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 5F4BD3D09D; Sat, 8 Aug 2009 02:22:04 +0200 (CEST) Date: Sat, 08 Aug 2009 02:22:04 +0200 (CEST) Message-Id: <20090808.022204.92569755.he@uninett.no> To: jnc@mercury.lcs.mit.edu From: Havard Eidnes In-Reply-To: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> X-Mailer: Mew version 5.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 00:22:03 -0000 > > the O UDP checksum proposal obsoletes all the today deployed no= des > > which check them (so all hosts I know and perhaps a lot of rout= ers too) > > OK, so what are the other options for encapsulating a packet in a IPv= 6 > packet? Um, surely, routers are not specified to validate layer-4 checksums for transit traffic?!? Let's look at this another way? As I understood it, UDP 0 would be used by LISP encapsulating/decapsulating devices. If some random (non-LISP encap/decap) host by mistake received a 0 UDP packet, it would be dropped, which should do no harm. In practical terms, only LISP encap/decap devices would need to be modified to accept 0 UDP packets under some specific rule / circumstance, as an exception to the general rule. The only thing which would prevent this would be one of conformance to the letter of the original spec, which apparently bans 0 UDP checksums. So what's so bad about that? Regards, - H=E5vard From gorry@erg.abdn.ac.uk Fri Aug 7 23:37:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462133A69E3; Fri, 7 Aug 2009 23:37:15 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BngkHXtYJ7zs; Fri, 7 Aug 2009 23:37:14 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 3D6DB3A697E; Fri, 7 Aug 2009 23:37:13 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n786ad3U014631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 07:36:40 +0100 (BST) Message-ID: <4A7D1CF7.8070004@erg.abdn.ac.uk> Date: Sat, 08 Aug 2009 07:36:39 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Noel Chiappa References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> In-Reply-To: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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: Sat, 08 Aug 2009 06:37:15 -0000 Noel Chiappa wrote: > > From: Francis Dupont > > > the O UDP checksum proposal obsoletes all the today deployed nodes > > which check them (so all hosts I know and perhaps a lot of routers too) > > OK, so what are the other options for encapsulating a packet in a IPv6 > packet? > > I'm told by some people that UDP-Lite isn't a standard yet? Or is it? (It > seems to have a protocol number issued?) Does UDP-Lite work through NAT > boxes? (LISP has a mobile-node mode, which we would like to see work through > NAT boxes, so any proposed alternative solution has to work through NAT boxes > too.) > > UDP-Lite spec: RFC 3828. UDP-Lite MIB: RFC 5097. Unicast UDP Usage Guidelines (for UDP and UDP-Lite): RFC 5405. UDP-Lite has been part of the Linux kernel since version 2.6.20. Gorry From brian@innovationslab.net Sat Aug 8 07:34:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023EA3A6BD3; Sat, 8 Aug 2009 07:34:40 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3C7zZjPpKsd; Sat, 8 Aug 2009 07:34:39 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id CE43A3A68DE; Sat, 8 Aug 2009 07:34:12 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9A9F58820E; Sat, 8 Aug 2009 07:34:15 -0700 (PDT) Received: from Clemson-2.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 13655130002; Sat, 8 Aug 2009 07:34:13 -0700 (PDT) Message-ID: <4A7D8CC0.1020809@innovationslab.net> Date: Sat, 08 Aug 2009 10:33:36 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: ipv6@ietf.org, lisp@ietf.org References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> <75cb24520908071822p3c196159p72f0ec395c64ff71@mail.gmail.com> In-Reply-To: <75cb24520908071822p3c196159p72f0ec395c64ff71@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: Christopher Morrow , jnc@mercury.lcs.mit.edu, Havard Eidnes Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 08 Aug 2009 14:34:40 -0000 Christopher Morrow wrote: > On Fri, Aug 7, 2009 at 8:22 PM, Havard Eidnes wrote: >>> > the O UDP checksum proposal obsoletes all the today deployed nodes >>> > which check them (so all hosts I know and perhaps a lot of routers too) >>> >>> OK, so what are the other options for encapsulating a packet in a IPv6 >>> packet? >> Um, surely, routers are not specified to validate layer-4 >> checksums for transit traffic?!? >> >> Let's look at this another way? As I understood it, UDP 0 would >> be used by LISP encapsulating/decapsulating devices. >> >> If some random (non-LISP encap/decap) host by mistake received a >> 0 UDP packet, it would be dropped, which should do no harm. > > warning this discssion morphed from a 'what should ipv6/ipv4 > translators do..' discssion. While a non-lisp node receiving a LISP > udp/0 packet dropping it seems fine to me, a translator dropping a > udp/0|null-sum packet instead of translating it properly or telling > the source-system: "oops, something bad happened" is unacceptable (in > my mind). > This statement about morphed discussions is absolutely correct. The discussion on the ipv6 mailing list should be about the proposals on the table for modifying the UDP checksum rules. Such a change impacts IPv4/IPv6 translators, LISP, and AMT. Please keep all other discussions (LISP behavior, translation techniques, etc.) on their respective lists. Thanks, Brian From dwmalone@maths.tcd.ie Sun Aug 9 13:02:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C9B3A6A89; Sun, 9 Aug 2009 13:02:15 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEy1UCljJhqY; Sun, 9 Aug 2009 13:02:15 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by core3.amsl.com (Postfix) with SMTP id 60BD33A6985; Sun, 9 Aug 2009 13:02:13 -0700 (PDT) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 9 Aug 2009 21:02:14 +0100 (BST) Date: Sun, 9 Aug 2009 21:02:09 +0100 From: David Malone To: Christopher Morrow Message-ID: <20090809200209.GA810@walton.maths.tcd.ie> References: <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> <75cb24520908071306x266d635bmf4377355affce2a6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75cb24520908071306x266d635bmf4377355affce2a6@mail.gmail.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 20:02:16 -0000 On Fri, Aug 07, 2009 at 04:06:16PM -0400, Christopher Morrow wrote: > > 4,166,900,871 packets 0 dropped due to bad checksum > > neat! (I'm also going to see if I can get some stats from a wider set > of hosts, but....) If routers check the IPv4 header checksum (which I think they are supposed to for IPv4), then I don't think you will see packets with IP checksum errors unless you are adjecent to a router/host that is generating bad checksums. For example, on one router I have access to that is exposed to a networks worth of random hardware, I've seen 2 bac IP checksums from 333128929 IP packets. On another home router I see 4 from 16089085. However, in IPv6, these errors will be forwarded on and show up as UDP or TCP checksum errors on end hosts. David. From Francis.Dupont@fdupont.fr Sun Aug 9 15:14:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9B23A6A8B; Sun, 9 Aug 2009 15:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSbjNmDDaLPJ; Sun, 9 Aug 2009 15:14:16 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id A0D2F3A6853; Sun, 9 Aug 2009 15:14:16 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n79MEHEM028385; Mon, 10 Aug 2009 00:14:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200908092214.n79MEHEM028385@givry.fdupont.fr> From: Francis Dupont To: Shane Amante In-reply-to: Your message of Fri, 07 Aug 2009 11:02:11 MDT. <27109484-9BF9-4ED9-B40D-DCB96788B074@castlepoint.net> Date: Mon, 10 Aug 2009 00:14:17 +0200 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Aug 2009 22:14:17 -0000 In your previous mail you wrote: > - if we need to vary things between a pair of IPv6 xTRs it should > be enough (and simple/easy) to vary the addresses The above was considered at the initial design stages of LISP, (I think Dino may have considered this approach?); however, it was shot down, because this would require the installers/administrators of the LISP ITR to both know the reasons why the above is required *and* configure the IPv6 ITR's with /64's to get the load-splitting benefits across LAG/ECMP paths. => I can't see the difference with varying the UDP source port. Instead, it's more 'straightforward' to just have the ITR's / => it is not more straightforward, you can put the hash where you'd like. automatically/ calculate a hash of the incoming IP packet and stuff that into the UDP source port before transmitting it out its uplinks toward the ETR. The key advantage of this approach is that ITR's / will/ be owned & operated by downstream customer's (i.e.: it's their CE's) who are likely unaware of and, therefore, may not care about the (extremely large) prevalence of LAG/ECMP paths through their upstream providers ... until congestion occurs in their upstream providers and they get upset. When in doubt, automatic == good. => you have just to put at least one of the end on a virtual link to get up to 64 bits of path selection. IMHO it is more than one could ever need... Thanks Francis.Dupont@fdupont.fr PS: IMHO this is an example of IPv6 misunderstanding: the solution was developed for IPv4 and as it doesn't fit exactly into IPv6 in place of adjusting the solution you propose to adjust IPv6. From Francis.Dupont@fdupont.fr Mon Aug 10 07:24:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB1E3A68A2; Mon, 10 Aug 2009 07:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg20a3BjUocn; Mon, 10 Aug 2009 07:24:26 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 197FE3A67B4; Mon, 10 Aug 2009 07:24:25 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n7AEOSRZ032456; Mon, 10 Aug 2009 16:24:28 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200908101424.n7AEOSRZ032456@givry.fdupont.fr> From: Francis Dupont To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-reply-to: Your message of Fri, 07 Aug 2009 15:31:11 EDT. <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> Date: Mon, 10 Aug 2009 16:24:28 +0200 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 10 Aug 2009 09:38:51 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 14:24:27 -0000 In your previous mail you wrote: > the O UDP checksum proposal obsoletes all the today deployed nodes > which check them (so all hosts I know and perhaps a lot of > routers too) OK, so what are the other options for encapsulating a packet in a IPv6 packet? => UDP-lite or a direct encapsulation (IMHO LISP should ask for a (IPv6) protocol number). I'm told by some people that UDP-Lite isn't a standard yet? Or is it? => RFC 3828, protocol 136. Does UDP-Lite work through NAT boxes? => I don't know but there is no deployed IPv6 NATs. Regards Francis.Dupont@fdupont.fr From dino@cisco.com Mon Aug 10 10:08:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2293A6E72; Mon, 10 Aug 2009 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.211 X-Spam-Level: X-Spam-Status: No, score=-7.211 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUutR8B0HBPB; Mon, 10 Aug 2009 10:08:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D31073A6B04; Mon, 10 Aug 2009 10:08:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIPxf0qrR7PE/2dsb2JhbAC5aYgrjm0FhBiBUQ X-IronPort-AV: E=Sophos;i="4.43,354,1246838400"; d="scan'208";a="225888452" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2009 17:08:40 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7AH8fSv011588; Mon, 10 Aug 2009 10:08:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7AH8f7G019277; Mon, 10 Aug 2009 17:08:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 10:08:41 -0700 Received: from [192.168.1.5] ([10.21.68.32]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 10:08:41 -0700 Message-Id: <150A17A6-D122-4ED3-BCD3-CF3DBE4F7470@cisco.com> From: Dino Farinacci To: Havard Eidnes In-Reply-To: <20090808.022204.92569755.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 10:08:40 -0700 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 10 Aug 2009 17:08:41.0369 (UTC) FILETIME=[35BF8090:01CA19DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1705; t=1249924121; x=1250788121; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Flow=20label=20redux |Sender:=20; bh=CcjaVJ/O6/hDJt7acvdMeU2r7rS+ymFE8L4fnvtqN4E=; b=s3kxatI/0t4l/yYBpIO2XwVAtAVyDA9t9/mWh38VJM5PWdu3UD8M2OAess 7TrFdmqAT7nV2Wdustt7E50ELnCgLpw98f1p570tcsWpj0ks0zE3NYneNEG2 KKvjTOWFso; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ipv6@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 17:08:38 -0000 >>> the O UDP checksum proposal obsoletes all the today deployed nodes >>> which check them (so all hosts I know and perhaps a lot of routers =20= >>> too) >> >> OK, so what are the other options for encapsulating a packet in a =20 >> IPv6 >> packet? > > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? Right, or have to build pseudo-headers in a contiguous buffer with the =20= *entire* data packet to calculate such a UDP checksum. > Let's look at this another way? As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. Right. But on the ETR, it is spec'ed to "ignore" checksums because =20 there are NATs that rewrite UDP checksum fields regardless if the NAT =20= receives the packet with a zero or non-zero UDP checksum. > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. As would a router (acting as a hsot) that is not doing LISP. > In practical terms, only LISP encap/decap devices would need to > be modified to accept 0 UDP packets under some specific rule / > circumstance, as an exception to the general rule. Right (modulo what I wrote above about ignoring UDP checksums on the =20 decapsulator). > The only thing which would prevent this would be one of > conformance to the letter of the original spec, which apparently > bans 0 UDP checksums. Right. > So what's so bad about that? Good question. Dino > > Regards, > > - H=E5vard > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Mon Aug 10 10:11:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CD13A68CE; Mon, 10 Aug 2009 10:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSdZwgvyjKHx; Mon, 10 Aug 2009 10:11:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AA19C3A6EE1; Mon, 10 Aug 2009 10:11:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B6EF74303DA; Mon, 10 Aug 2009 10:11:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AABAC4303BC; Mon, 10 Aug 2009 10:11:26 -0700 (PDT) Message-ID: <4A8054BD.8090508@joelhalpern.com> Date: Mon, 10 Aug 2009 13:11:25 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Havard Eidnes References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> In-Reply-To: <20090808.022204.92569755.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 17:11:24 -0000 Actually, looking at this as a LISP problem is probalby misleading. This issue applies to any intermediate device based, high capacity, tunnel mechanism. 1) High capacity tunnel mechanisms are going to be concerned to implement in hardware, where the UDP checksum may be difficult 2) High capacity tunnels are the very ones whose traffic could and should make use of ECMP / LAG operation. Starting from there, the line of argument then proceeds to look at what works. What works in the real world IPv6 deployments is UDP with 0 checksum. That enables ECMP / LAG without excessive effort / overhead. Note that UDP-lite is not an answer in terms of what works now. The vast majority of deployed provider-edge (PE) and provider-core (P) devices will not look at the port numbers in the UDP-lite header because they do not recognize the protocol. The next question is whether this could change. I am still collecting information on this. Product seems to fall into three categories: 1) Software forwarders. Obviously, these can change 2) Microcoded packet processors - These can probably change which field is looked at, within limits 3) Hardware mechanisms - these really can not change their handling, as they are in the field. Preliminary data indicates that there are a non-trivial number of hardware devices already out there and handling IPv6. There are a noticeable number of core devices that could be changed in small ways (microcoded or software), for example to use the flow-label instead of some other piece of information in the packet. We can look at the hardware and complain, or we can look at it and thank the vendor for acting promptly on RFCs. We can not reasonably expect the hardware to change in any meaningful time frame. I am still colelcting implementation data, so I may be misled by what I have gotten. But it seems to me that we are unfortunately stuck with UDP with 0 checksums if we want high capacity tunnels to be able to make use of ECMP / LAG in the moderate time period (out through at least 5 years, maybe longer.) Yours, Joel Havard Eidnes wrote: >> > the O UDP checksum proposal obsoletes all the today deployed nodes >> > which check them (so all hosts I know and perhaps a lot of routers too) >> >> OK, so what are the other options for encapsulating a packet in a IPv6 >> packet? > > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? > > Let's look at this another way? As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. > > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. > > In practical terms, only LISP encap/decap devices would need to > be modified to accept 0 UDP packets under some specific rule / > circumstance, as an exception to the general rule. > > The only thing which would prevent this would be one of > conformance to the letter of the original spec, which apparently > bans 0 UDP checksums. > > So what's so bad about that? > > Regards, > > - Hĺvard > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From rcallon@juniper.net Mon Aug 10 11:25:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229F128C0F0; Mon, 10 Aug 2009 11:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psxEJ8qisGxJ; Mon, 10 Aug 2009 11:24:59 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0BAE73A69BF; Mon, 10 Aug 2009 11:24:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSoBl++4Y+O7qA/d+o9CDtUdIzlZvT5B/@postini.com; Mon, 10 Aug 2009 11:25:03 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 Aug 2009 11:20:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 10 Aug 2009 14:20:04 -0400 From: Ross Callon To: "Joel M. Halpern" , Havard Eidnes Date: Mon, 10 Aug 2009 14:20:02 -0400 Thread-Topic: [lisp] Flow label redux Thread-Index: AcoZ3awgQ9fS2alLRfajspTo+87pdQAAYULw Message-ID: References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> <4A8054BD.8090508@joelhalpern.com> In-Reply-To: <4A8054BD.8090508@joelhalpern.com> Accept-Language: en-US Content-Language: en-US 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: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 18:25:00 -0000 I agree with Joel that this problem is broader than just LISP. This is an i= ssue with any device that is encapsulating quite a bit of traffic (that rep= resents many smaller flows that could be split) in a tunnel over IPv6. It w= ould (IMHO) serve us well to do this right.=20 I also agree with Joel that there is a wide range of existing equipment dep= loyed, and at least some of the existing high speed (core) IPv6 routers cou= ld include the flow label in the hash, at the cost of a microcode software = update, and probably removing something else from the hash.=20 There isn't all that much IPv6 traffic right now (some please correct me if= this is wrong), and the ramp-up speed seems relatively slow. Thus to me it= seems that the time frame that it would take to change router hardware is = long, but no longer than the time frame that it is likely before we find ou= rselves with enough IPv6 traffic that we actually need to do a good job of = ECMP splitting of traffic going over an IPv6 tunnel. Thus I think that it w= ould be okay to do this by putting a hash of higher layer flow information = into the flow field, if we think that is the right way to do it.=20 Ross=20 (speaking as an individual contributor with my own personal opinion only).= =20 -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Joe= l M. Halpern Sent: 10 August 2009 13:11 To: Havard Eidnes Cc: ipv6@ietf.org; lisp@ietf.org Subject: Re: [lisp] Flow label redux Actually, looking at this as a LISP problem is probalby misleading. This issue applies to any intermediate device based, high capacity,=20 tunnel mechanism. 1) High capacity tunnel mechanisms are going to be concerned to=20 implement in hardware, where the UDP checksum may be difficult 2) High capacity tunnels are the very ones whose traffic could and=20 should make use of ECMP / LAG operation. Starting from there, the line of argument then proceeds to look at what=20 works. What works in the real world IPv6 deployments is UDP with 0 checksum.=20 That enables ECMP / LAG without excessive effort / overhead. Note that UDP-lite is not an answer in terms of what works now. The=20 vast majority of deployed provider-edge (PE) and provider-core (P)=20 devices will not look at the port numbers in the UDP-lite header because=20 they do not recognize the protocol. The next question is whether this could change. I am still collecting=20 information on this. Product seems to fall into three categories: 1) Software forwarders. Obviously, these can change 2) Microcoded packet processors - These can probably change which field=20 is looked at, within limits 3) Hardware mechanisms - these really can not change their handling, as=20 they are in the field. Preliminary data indicates that there are a non-trivial number of=20 hardware devices already out there and handling IPv6. There are a noticeable number of core devices that could be changed in=20 small ways (microcoded or software), for example to use the flow-label=20 instead of some other piece of information in the packet. We can look at the hardware and complain, or we can look at it and thank=20 the vendor for acting promptly on RFCs. We can not reasonably expect the hardware to change in any meaningful=20 time frame. I am still colelcting implementation data, so I may be misled by what I=20 have gotten. But it seems to me that we are unfortunately stuck with=20 UDP with 0 checksums if we want high capacity tunnels to be able to make=20 use of ECMP / LAG in the moderate time period (out through at least 5=20 years, maybe longer.) Yours, Joel Havard Eidnes wrote: >> > the O UDP checksum proposal obsoletes all the today deployed nodes >> > which check them (so all hosts I know and perhaps a lot of routers= too) >> >> OK, so what are the other options for encapsulating a packet in a IPv6 >> packet? >=20 > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? >=20 > Let's look at this another way? As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. >=20 > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. >=20 > In practical terms, only LISP encap/decap devices would need to > be modified to accept 0 UDP packets under some specific rule / > circumstance, as an exception to the general rule. >=20 > The only thing which would prevent this would be one of > conformance to the letter of the original spec, which apparently > bans 0 UDP checksums. >=20 > So what's so bad about that? >=20 > Regards, >=20 > - H=E5vard > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From christopher.morrow@gmail.com Mon Aug 10 11:41:12 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF1A3A6EA7; Mon, 10 Aug 2009 11:41:11 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIblt65nt-JS; Mon, 10 Aug 2009 11:41:10 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id B12AB3A6E60; Mon, 10 Aug 2009 11:41:09 -0700 (PDT) Received: by qyk41 with SMTP id 41so3047737qyk.29 for ; Mon, 10 Aug 2009 11:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=8bYrp02m7gTdKjwNzwrNpGPGyYWzylqab7kWKU+rRds=; b=oeC0kzoFS3sBbt/uzFpEp/8aTBvkOobRC/Hyusn+du2rq74Utsg5TOiiCwAQAMMv2t EKtVwiLfoeTgtDOz4Hzq2R1G7On90yN3KR+1/ytcDmUnogoMjzAruSpM7a4oFRSptlKV rI8Ff35HxJHzeeXPntmWtTLfRGti9Se9rznns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kvjxM0KBnNRJTt6L3aA2EfuBHRfqyFkjgOq24mmps7z6tkV1u60RpxJKK9uBzOBMAE 5ZBJ0rlyj8f8A5qdqCuTcmQWHvGR+MDyk7cInbgIvD3SDEcM0emwxDErWDGs1sXDuSTM K/FdJlrabCW1+fdbq9CofVtM1FchfURmq/Aug= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.74.21 with SMTP id s21mr3504721qaj.60.1249929669782; Mon, 10 Aug 2009 11:41:09 -0700 (PDT) In-Reply-To: References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> <4A8054BD.8090508@joelhalpern.com> Date: Mon, 10 Aug 2009 14:41:09 -0400 X-Google-Sender-Auth: 1141e6678a94977d Message-ID: <75cb24520908101141u503b0459h2b57bfe688b12fa4@mail.gmail.com> From: Christopher Morrow To: Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Havard Eidnes Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Aug 2009 18:41:12 -0000 On Mon, Aug 10, 2009 at 2:20 PM, Ross Callon wrote: > There isn't all that much IPv6 traffic right now (some please correct me if this is wrong), and the ramp-up speed seems relatively 'much global ipv6 traffic'. There are places with more ipv6 traffic, where LAG/ECMP is important. These 'internet protocols' get used on 'not the internet' networks as well. Additionally, across links not gig in size, but still lag/ecmp-aware. > slow. Thus to me it seems that the time frame that it would take to change router hardware is long, but no longer than the time > frame that it is likely before we find ourselves with enough IPv6 traffic that we actually need to do a good job of ECMP splitting of 'enough global/public ipv6 traffic' - I would caution that there are places where LAG/ECMP is necessary today, or will be in the very near future, that are not publicly visible. > traffic going over an IPv6 tunnel. Thus I think that it would be okay to do this by putting a hash of higher layer flow information into > the flow field, if we think that is the right way to do it. -chris From mrw@sandstorm.net Mon Aug 10 19:26:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8D73A6AA9 for ; Mon, 10 Aug 2009 19:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCDPNVZXvg4f for ; Mon, 10 Aug 2009 19:26:09 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AFE9D3A6A94 for ; Mon, 10 Aug 2009 19:26:09 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B2PkC9068868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:25:53 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <70A6D2F1-A345-40BF-AF92-F62E22A5A3E1@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 22:25:46 -0400 References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 02:26:10 -0000 Hi Noel, On Aug 6, 2009, at 6:44 PM, Noel Chiappa wrote: > I guess I don't see that there's a big problem here, if the _outer_ > IPv6 > header is damaged. The inner packet (either v4, or v6) will still > have its > checksum(s) to protect it. > > I'm trying to understand what all the possible failure modes are if > the outer > header is damaged. Here are the ones I can think of: > > - The packet may arrive at the wrong destination, which should > either i) not > recognize it (because it's not an ETR - I don't recall if LISP uses > registered ports, if not at some point we should apply for some), or > ii) LISP currently lists an explicit port number in the draft. Hopefully that will turn into an IANA request. Or, if the port is already registered to LISP, it should become a reference to the IANA allocation. > > unwrap it and discover that that EID is not at that ETR (which is a > failure > that can happen for other reasons, so has to be handled). Will an error be sent back to the originating ITR when this happens, so that it knows that it should try to update its mapping cache? > > > - The packet may arrive with a damaged source address. This may > cause a > bogus 'partner ITR' entry to be created (e.g. for the echo nonce > entry), > but I can't think of any real problems that will happen in this case. Ummm... Wouldn't this cause end-nodes behind the destination ETR to be unable to initiate connections to the original source EID until the incorrect mapping is corrected? For example, if EID 128.127.2.105 sends a packet that gets encapsulated by the ITR to include a source RLOC of 12.0.0.1, but the source RLOC gets corrupted to 15.0.0.1, the receiving xTR will set-up a mapping that indicates that EID 128127.2.105 is reached via RLOC 15.0.0.1 and will send the packet on to its proper destination. However, when the destination end node tries to respond, the response will go to EID 128.127.2.105 at RLOC 15.0.0.1, and it will be discarded. Also, no other node behind the destination xTR would be able to reach EID 128127.2.105 until the incorrect mapping is cleared or corrected. There is some mention in the spec about verifying automatic mappings with the mapping system, but there are no specifics about how/when/if this will be done. Thoughts? If this is a real issue, it is also a potential security problem, as there is nothing preventing a node from sending a packet containing an invalid EID/RLOC source pair, explicitly to create an incorrect mapping entry. > Maybe I'm not very awake today, but that's all I can come up with > off the top > of my head? Other errors (e.g. bashing the hop count) may cause the > packet to > be discarded in transit, but that can happen anyway. Discarded packets are uninteresting, as all the checksum would do is cause the packets to be discarded. So, either way, some packets will be discarded, or simply lost for other reasons. There is one other case that I think we should be clear about: If the destination address is corrupted and the packet arrives at a non-LISP node, that node will send back an ICMP "port unreachable" message. We should make sure that the LISP node that receives the ICMP error will handle it correctly -- in this case, just discard it. In general, the LISP spec seems to lack information about how to handle, and when to generate, ICMP errors. > In general, the reliance on explict control traffic (which is > protected from > error by checksums - "The UDP Checksum is computed and set to non- > zero for > Map-Request and Map-Reply messages") for most functions should help > with > robustness. I agree. It would be _much_ more of a concern if these packets used zero checksums. > > There are a _few_ functions which are piggybacked on user data > traffic, and > as alluded to in a prior message, we do have to be careful in > designing them, > to make sure they aren't affectable by damaged headers. So far that > has > been no problem. When you say this has been no problem, do you mean in the experimental LISP network? I'd be interested to know more about how that network is configured, so that I could understand if it is likely to be representative of real-world deployment in terms of these types of problems. Is there a site that describes that network in detail? Margaret From mrw@sandstorm.net Mon Aug 10 19:31:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669303A6D96 for ; Mon, 10 Aug 2009 19:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO7i8CFpYxHi for ; Mon, 10 Aug 2009 19:31:15 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8520A3A6D05 for ; Mon, 10 Aug 2009 19:31:15 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B2VGDw069160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:31:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <4A927775-C35F-4374-BCEA-F866F95C455A@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090807122736.266556BE55F@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 22:31:15 -0400 References: <20090807122736.266556BE55F@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 02:31:16 -0000 Hi Noel, On Aug 7, 2009, at 8:27 AM, Noel Chiappa wrote: >> From: Sam Hartman > >> Under the current lisp-03 spec, an ETR receiving such a packet is >> allowed to create a gleaned cache entry for the source EID in the >> packet, using the outer RLOC .. for communication with that EID. >> >> Nothing in the current spec mandates that the ETR send a confirming >> map-request, and I believe the default TTL is rather long. > > Is that [still] in the spec? (I've seen so many versions of the main > spec > document I have a hard time forcing myself to read them any > more! :-) If it's > still there, yes, it's an issue. > > I thought that that was either i) something associated with other > 'versions' > of LISP (or perhaps 'deployment models' is more accurate terminology > than > "versions" - I'm talking about things like 'LISP 1', where there is no > mapping system), or ii) something that had been deprecated as a DoS > vector > (send someone a bogus packet, and pollute their mapping cache). Yes, this is still in the spec. Of course, the spec also still includes the list of various LISP "versions", and other text that clearly only applies to versions that we are not planning to fully specify. It would be very helpful if the LISP authors could clean up the spec to specify only the version of LISP we are attempting to document, so that there wouldn't be any ambiguity about what applies to "this version" and what doesn't. Margaret From mrw@sandstorm.net Mon Aug 10 19:41:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B93E3A6C78; Mon, 10 Aug 2009 19:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw5eabYxnY2g; Mon, 10 Aug 2009 19:41:27 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 0C6D63A67EC; Mon, 10 Aug 2009 19:41:26 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B2fN6u069482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:41:24 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1312CA4A-BB2F-4F7E-AC63-8BAEBA8AC682@sandstorm.net> From: Margaret Wasserman To: Francis Dupont In-Reply-To: <200908071524.n77FONdo014337@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 22:41:23 -0400 References: <200908071524.n77FONdo014337@givry.fdupont.fr> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 02:41:28 -0000 On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote: > => in fact the IPv6 addresses don't need to be the same when xTRs are > attached to regular links with /64 prefixes. So IMHO most of this > discussion is insane: > - if we need to vary things between a pair of IPv6 xTRs it should > be enough (and simple/easy) to vary the addresses This is an interesting idea, and I think it is worth exploring. However, there are a couple of issues to overcome... Would you perform DAD on these addresses before you use them? Or would you somehow delegate a prefix (perhaps longer than a /64) to each xTR for this purpose? > > - the O UDP checksum proposal obsoletes all the today deployed nodes > which check them (so all hosts I know and perhaps a lot of routers > too), > so if we believe something has to be fixed some routers should be > fixed > and not all BSD/Linux/MacOS/Windows boxes (software and hardware). I think that the idea is that the IPv6 UDP headers with zero checksums will only be sent between the ITR and ETR, so it is only LISP nodes that need to change. However, I personally would like to be able to implement a compliant LISP node (ITR and ETR) on a desktop operating system like Windows or Unix, and I don't think that one can expect deployed desktop operating systems to be updated (to allow zero UDP checksums in IPv6) any faster than the estimates given for routing updates (3-5 years). Also, the last time I dealt with zero UDP checksums (mid 1990s), it was only possible to disable UDP checksums (for IPv4) in the unix kernel, so they were on or off for the entire box. Have things evolved since then? Is it possible to have IPv4 UDP checksums enabled (both calculating them and checking them) for some sockets while they are disabled (set to zero, and not checked on receipt) for other sockets? If so, what sockets option is commonly used for this in Unix operating systems? Thanks, Margaret From mrw@sandstorm.net Mon Aug 10 19:50:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311923A6844; Mon, 10 Aug 2009 19:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGg8WA98sJg0; Mon, 10 Aug 2009 19:50:09 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5FE3C3A6A1D; Mon, 10 Aug 2009 19:50:09 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B2oAtJ069860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:50:11 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1AFDBBB2-665C-4F53-9566-685EC826B58E@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 22:50:10 -0400 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 02:50:10 -0000 Hi Noel, On Aug 7, 2009, at 3:31 PM, Noel Chiappa wrote: >> From: Francis Dupont >> the O UDP checksum proposal obsoletes all the today deployed nodes >> which check them (so all hosts I know and perhaps a lot of routers >> too) > > OK, so what are the other options for encapsulating a packet in a IPv6 > packet? We could just do an IP-in-IP encapsulation, so the headers would be IPv6-LISP-IP(v4 or v6), but that does not address the LAG/ECMP concern. > > I'm told by some people that UDP-Lite isn't a standard yet? Or is > it? (It > seems to have a protocol number issued?) Does UDP-Lite work through > NAT > boxes? (LISP has a mobile-node mode, which we would like to see work > through > NAT boxes, so any proposed alternative solution has to work through > NAT boxes > too.) UDP-Lite is a proposed standard, RFC 3828. > > Also, hosts aren't an issue - and in fact it's a _feature_ that > hosts will > discard any LISP packets they see (for having bad checksums). Unless the host implements LISP. See my earlier message on this subject... Do we think it will be possible to disable IPv6 UDP checksums everywhere that LISP needs to run? On many of today's host systems, sending a UDP packet with a zero checksum is simply treated as an indication that the NIC card should perform the checksum. Margaret From mrw@sandstorm.net Mon Aug 10 19:53:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467323A6844; Mon, 10 Aug 2009 19:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0DDisVBuzyh; Mon, 10 Aug 2009 19:53:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 73FB728C0E2; Mon, 10 Aug 2009 19:53:05 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B2r4Nh070019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 22:53:04 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <99D56D74-9C01-4C95-AA37-461CE088612F@sandstorm.net> From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 22:53:04 -0400 References: <7E300063-9664-4405-82D6-DA82DB49B06B@castlepoint.net> <11322FFB-FF74-4C64-B468-483C3BAE12ED@sandstorm.net> <75cb24520908051154g352ee2f8x8abdbe550dc2a773@mail.gmail.com> <13FE7E35-81D0-4D34-9AEC-E56B72886FAB@sandstorm.net> <75cb24520908051255x5c8794e3rb3b1acdfc613b815@mail.gmail.com> <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 02:53:06 -0000 >> >> The dataset analyzed is not relevant to today's networking >> connectivity or technologies. Looking very quickly at a small set of >> data I have access to (servers serving web content to the internet >> users): >> >> 32,945,810,591 packets received, 0 dropped due to bad checksum (ip >> header checksum) >> >> 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no >> checksum (udp datagram stats) > > Just polling the routers here, I see a similar scenario, e.g., > > 4,166,900,871 packets 0 dropped due to bad checksum Marshal, do your routers actually calculate the checksums of the packets they process? Shane, are you sure that checksums aren't be calculated lower down in the hardware than your counters are counting? I have seen cases where error counters showed up as zero, because the packets that would have invoked those errors were already discarded at a lower level. Margaret From mrw@sandstorm.net Mon Aug 10 20:02:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30223A6A1D; Mon, 10 Aug 2009 20:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2okLBtqwelqA; Mon, 10 Aug 2009 20:02:30 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 06AC43A6844; Mon, 10 Aug 2009 20:02:29 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B32CYn070378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 23:02:18 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1820CB68-042B-49A3-8F09-5160E5F330EF@sandstorm.net> From: Margaret Wasserman To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 23:02:12 -0400 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 03:02:30 -0000 > >> Does UDP-Lite work through NAT >> boxes? (LISP has a mobile-node mode, which we would like to see >> work through >> NAT boxes, so any proposed alternative solution has to work through >> NAT boxes >> too.) > > For IPv6? Sorry I didn't reply to this in the earlier message... (1) There isn't enough NAT deployment for IPv6 (yet) to know how IPv6 NAT boxes will behave. It is possible to implement at v6 NAT that doesn't touch the transport headers at all. (2) I've heard statements about LISP working through NATs, but I can't figure out how that would work... Could you explain to me how LISP would work using IPv4 encapsulation behind an IPv4 NAT? Are you expecting that there will be LISP ALGs to convert the inner headers as they are transmitted through the NAT in the outbound direction? Otherwise, it seems like EIDs from private address space (such as net 10) will get injected into other networks, where they will be meaningless. Margaret From mrw@sandstorm.net Mon Aug 10 20:09:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720AA3A6B3B; Mon, 10 Aug 2009 20:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkoZoNZRIA2w; Mon, 10 Aug 2009 20:09:31 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 696B83A6DC1; Mon, 10 Aug 2009 20:08:54 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B38t1r070549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 23:08:56 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3D8BE8B8-E13E-4004-8286-BBE80BC9145B@sandstorm.net> From: Margaret Wasserman To: Havard Eidnes In-Reply-To: <20090808.022204.92569755.he@uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 23:08:55 -0400 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> <20090808.022204.92569755.he@uninett.no> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 03:09:32 -0000 Hi Havard, On Aug 7, 2009, at 8:22 PM, Havard Eidnes wrote: >>> the O UDP checksum proposal obsoletes all the today deployed nodes >>> which check them (so all hosts I know and perhaps a lot of routers >>> too) >> >> OK, so what are the other options for encapsulating a packet in a >> IPv6 >> packet? > > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? > > Let's look at this another way? As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. > > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. So, you are assuming that LISP is the _only_ protocol that will choose to specify zero UDP checksums? And that LISP will be implemented solely on systems that implement LISP and no other protocols? Margaret From mrw@sandstorm.net Mon Aug 10 20:17:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3043A6E58 for ; Mon, 10 Aug 2009 20:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdwPtCzipIqs for ; Mon, 10 Aug 2009 20:17:52 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 0D0223A676A for ; Mon, 10 Aug 2009 20:17:51 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B3Hmpo070886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 23:17:49 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <01512C00-9E91-4864-AE02-95F745F1DB98@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <82C32A62-89FD-4F43-BACC-1C9C9D4BDEDF@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 23:17:48 -0400 References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> <82C32A62-89FD-4F43-BACC-1C9C9D4BDEDF@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 03:17:53 -0000 On Aug 8, 2009, at 8:29 PM, Dino Farinacci wrote: >> >> I'm sending this message, mainly to indicate that the problem of >> outer >> header corruption is one that requires real technical thought and >> that >> has non-obvious consequences. > > Are you worried the header is going to be corrupt and the link layer > will not catch it? Research has shown that data corruption is far more likely to occur inside network equipment (e.g. from bus errors in routers and switches) than on the data link. The data link CRC won't catch that problem, since it is recalculated at each hop. >> It may well be that we can design a LISP for which the possibility of >> outer header corruption is acceptable and for which we can convince >> ourselves of this fact. > > Are we talking about security or bit-errors? Let's be real clear here. Both. We should make sure that LISP does not fail catastrophically in the presence of unintentional or intentional packet corruption. >> >> Nothing in the current spec mandates that the ETR send a confirming >> map-request, and I believe the default TTL is rather long. > > Yes the spec does say that. Really. How soon is it required to do the confirmation? And what is it expected to do with packets destined to the source EID in the meantime? Could you quote the section of the spec that says this, because that is not how I read it... > > So the only way this would happen is if there was a bit-error from > the last-hop that forwarded the packet to the ETR router. Is that > what yo want to focus the discussion on? Actually, an error inside any router or switch in the path could cause the headers that are received at the ETR to be corrupted. >> It is clearly the case with today's LISP spec that a single corrupted >> packet is permitted to disrupt communications between two lisp nodes >> for a significant period of time. > > There is nothing in the spec that says *this is permitted*. However, it does say that the use of "gleaned" mappings is allowed, and places no specific limitations on their use. Margaret From mrw@sandstorm.net Mon Aug 10 20:22:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BB63A6B22; Mon, 10 Aug 2009 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY46eZVbVu7I; Mon, 10 Aug 2009 20:22:32 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 375323A6F01; Mon, 10 Aug 2009 20:22:32 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7B3MWip071122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 23:22:32 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 10 Aug 2009 23:22:32 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 03:22:33 -0000 On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: > > The spec says ETRs MUST ignore the UDP checksum field. This is what > the LISP authors intended and has been implemented this way. > > The spec says ITRs MUST set the UDP checksum field to 0. Could you tell us how to achieve this on commonly deployed desktop software/hardware that has two properties: - There is no means to turn off the checking of UDP checksums. They will be checked if they are non-zero in IPv4, and they will be checked in all cases in IPv6 with zero always being considered invalid. - Networking Interface Cards that automatically calculate TCP/UDP checksums on transmission if a checksum of zero is sent to the card. Systems with these properties are far more widely deployed than LAG/ ECMP routers, and they are no easier/quicker to update. Margaret From luigi@net.t-labs.tu-berlin.de Tue Aug 11 00:57:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B347F3A67EB; Tue, 11 Aug 2009 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuvUFGI0qU3Q; Tue, 11 Aug 2009 00:57:58 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 8568C3A6B18; Tue, 11 Aug 2009 00:57:58 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 4ADD77064D60; Tue, 11 Aug 2009 09:58:01 +0200 (CEST) Message-Id: <4688BD0B-0CF7-4B7C-9E5F-D12A41D4B295@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Margaret Wasserman In-Reply-To: <1312CA4A-BB2F-4F7E-AC63-8BAEBA8AC682@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 09:58:00 +0200 References: <200908071524.n77FONdo014337@givry.fdupont.fr> <1312CA4A-BB2F-4F7E-AC63-8BAEBA8AC682@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Francis Dupont , ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 07:57:59 -0000 On Aug 11, 2009, at 4:41 , Margaret Wasserman wrote: > > On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote: >> => in fact the IPv6 addresses don't need to be the same when xTRs are >> attached to regular links with /64 prefixes. So IMHO most of this >> discussion is insane: >> - if we need to vary things between a pair of IPv6 xTRs it should >> be enough (and simple/easy) to vary the addresses > > This is an interesting idea, and I think it is worth exploring. > However, there are a couple of issues to overcome... > > Would you perform DAD on these addresses before you use them? Or > would you somehow delegate a prefix (perhaps longer than a /64) to > each xTR for this purpose? >> >> - the O UDP checksum proposal obsoletes all the today deployed nodes >> which check them (so all hosts I know and perhaps a lot of routers >> too), >> so if we believe something has to be fixed some routers should be >> fixed >> and not all BSD/Linux/MacOS/Windows boxes (software and hardware). > > I think that the idea is that the IPv6 UDP headers with zero > checksums will only be sent between the ITR and ETR, so it is only > LISP nodes that need to change. > > However, I personally would like to be able to implement a compliant > LISP node (ITR and ETR) on a desktop operating system like Windows > or Unix, and I don't think that one can expect deployed desktop > operating systems to be updated (to allow zero UDP checksums in > IPv6) any faster than the estimates given for routing updates (3-5 > years). If you want LISP on a desktop OS you need to update that OS, hence at the same time you can patch it to handle the 0 UDP checksum consequently. I do not see any real issue here. Luigi > > Also, the last time I dealt with zero UDP checksums (mid 1990s), it > was only possible to disable UDP checksums (for IPv4) in the unix > kernel, so they were on or off for the entire box. Have things > evolved since then? Is it possible to have IPv4 UDP checksums > enabled (both calculating them and checking them) for some sockets > while they are disabled (set to zero, and not checked on receipt) > for other sockets? If so, what sockets option is commonly used for > this in Unix operating systems? > > Thanks, > Margaret > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Tue Aug 11 05:25:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328103A6B67; Tue, 11 Aug 2009 05:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stQ3vp49GQOX; Tue, 11 Aug 2009 05:25:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 678863A7097; Tue, 11 Aug 2009 05:25:05 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BCNWCN099503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 08:23:33 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <9CE47ECF-340C-4846-A053-C03F19EB9590@sandstorm.net> From: Margaret Wasserman To: Luigi Iannone In-Reply-To: <4688BD0B-0CF7-4B7C-9E5F-D12A41D4B295@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 08:23:31 -0400 References: <200908071524.n77FONdo014337@givry.fdupont.fr> <1312CA4A-BB2F-4F7E-AC63-8BAEBA8AC682@sandstorm.net> <4688BD0B-0CF7-4B7C-9E5F-D12A41D4B295@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.935.3) Cc: Francis Dupont , ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 12:25:06 -0000 On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote: > > If you want LISP on a desktop OS you need to update that OS, hence > at the same time you can patch it to handle the 0 UDP checksum > consequently. I do not see any real issue here. So, if I want LISP on a non-open-source desktop, you think I should just wait until the OS vendor gives it to me? Why is this any more reasonable than telling ISPs that if they want to support LAG/ECMP for LISP flows, they need to buy new routers? Margaret From mrw@sandstorm.net Tue Aug 11 05:29:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FA53A7099; Tue, 11 Aug 2009 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO7lomdJ6rlC; Tue, 11 Aug 2009 05:29:44 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E83263A7124; Tue, 11 Aug 2009 05:29:08 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BCSb6n099945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 08:28:38 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <60641141-3600-4A7E-B4DD-956E2D5DCFAC@sandstorm.net> From: Margaret Wasserman To: sthaug@nethelp.no In-Reply-To: <20090811.101123.74696609.sthaug@nethelp.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 08:28:36 -0400 References: <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> <99D56D74-9C01-4C95-AA37-461CE088612F@sandstorm.net> <20090811.101123.74696609.sthaug@nethelp.no> X-Mailer: Apple Mail (2.935.3) Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 12:29:44 -0000 Hi Steinar, On Aug 11, 2009, at 4:11 AM, sthaug@nethelp.no wrote: >>>> The dataset analyzed is not relevant to today's networking >>>> connectivity or technologies. Looking very quickly at a small set >>>> of >>>> data I have access to (servers serving web content to the internet >>>> users): >>>> >>>> 32,945,810,591 packets received, 0 dropped due to bad checksum (ip >>>> header checksum) >>>> >>>> 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no >>>> checksum (udp datagram stats) > > Checking six of our name servers here (some pure recursive, some pure > authoritative): > > - 11,125,766,153 IP packets received, with 0 bad header checksums > - 9,311,954,730 UDP datagrams received, with 1,300,228 bad checksums > > Thus IP header checksum really looks like it is very close to zero, > probably because any IP packets with bad header checksums would be > dropped by the closest router. If LISP uses UDP checksums of zero with IPv6, packets with IP header corruption will not be dropped by the next router, they will be forwarded all the way to the ETR (or, in the case of destination address corruption) all the way to the wrong ETR or a non-LISP end-node. > > However, the UDP bad checksum rate is very definitely not zero. I > get a rate of 1.39e-4 for my dataset. This is potentially an argument for using UDP (or UDP-Lite) checksums in LISP for both IPv4 and IPv6, so that the corruption in the outer UDP header and the LISP header will be detected before these packets are processed on the remote end. Margaret From hartmans@mit.edu Tue Aug 11 05:44:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EC93A712C for ; Tue, 11 Aug 2009 05:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpDenmM9-xP for ; Tue, 11 Aug 2009 05:44:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C91C63A6AF2 for ; Tue, 11 Aug 2009 05:43:38 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9353A51C5; Tue, 11 Aug 2009 08:42:32 -0400 (EDT) To: Dino Farinacci References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> <4AA28E27-1132-4C12-9FBE-898E9EB6DE90@cisco.com> From: Sam Hartman Date: Tue, 11 Aug 2009 08:42:32 -0400 In-Reply-To: <4AA28E27-1132-4C12-9FBE-898E9EB6DE90@cisco.com> (Dino Farinacci's message of "Fri\, 7 Aug 2009 12\:47\:21 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 12:44:39 -0000 >>>>> "Dino" == Dino Farinacci writes: >> 2) Document why you'd use UDP, not IPIP or udp-light. Dino> This is already in the spec. You say that UDP is used for LAGs. I definitely didn't see a good discussion of other options that were considered and rejected. It's my opinion as a chair that the issue must be documented. It's my opinion as an individual that the current documentation is inadequate. Factors that lead to this conclusion include reading the documentation and the amount of discussion this issue has generated from people who have read the spec. From hartmans@mit.edu Tue Aug 11 05:55:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39783A70EE for ; Tue, 11 Aug 2009 05:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXe7-fpHtpWS for ; Tue, 11 Aug 2009 05:55:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 029593A6FF6 for ; Tue, 11 Aug 2009 05:55:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 87DF7641DA; Tue, 11 Aug 2009 08:55:12 -0400 (EDT) To: Dino Farinacci References: <20090806224422.3268A6BE56B@mercury.lcs.mit.edu> <82C32A62-89FD-4F43-BACC-1C9C9D4BDEDF@cisco.com> From: Sam Hartman Date: Tue, 11 Aug 2009 08:55:12 -0400 In-Reply-To: <82C32A62-89FD-4F43-BACC-1C9C9D4BDEDF@cisco.com> (Dino Farinacci's message of "Sat\, 8 Aug 2009 17\:29\:42 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 12:55:27 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Speaking as an individual for the moment: >> >>>>>>> "Noel" == Noel Chiappa writes: Noel> - The packet may arrive with a damaged source address. This Noel> may cause a bogus 'partner ITR' entry to be created Noel> (e.g. for the echo nonce entry), but I can't think of any Noel> real problems that will happen in this case. >> >> >> I'm sending this message, mainly to indicate that the problem >> of outer header corruption is one that requires real technical >> thought and that has non-obvious consequences. Dino> Are you worried the header is going to be corrupt and the Dino> link layer will not catch it? I'm using the same model of corruption that the IETF seems to have consensus behind; Margaret forwarded you links to research papers that put forward a model. This model seems to have reasonably wide acceptance in the transport and internet area of the IETF. If you have other research papers you want to put forward with a different model then that would be very interesting and would definitely help inform the discussion. >> It may well be that we can design a LISP for which the >> possibility of outer header corruption is acceptable and for >> which we can convince ourselves of this fact. Dino> Are we talking about security or bit-errors? Let's be real Dino> clear here. At this point I'm talking about bit errors. I've been thinking some about security although I've not said anything on the list about security. However in this thread I'm talking about bit errors. From luigi@net.t-labs.tu-berlin.de Tue Aug 11 06:22:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054063A7053; Tue, 11 Aug 2009 06:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTTo+w+vdpT5; Tue, 11 Aug 2009 06:22:24 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 31D2C3A6A0A; Tue, 11 Aug 2009 06:22:24 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id EF5F0701BA9C; Tue, 11 Aug 2009 14:44:02 +0200 (CEST) Message-Id: <5305ACCA-612D-44E2-90D1-C20BAE0458F4@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Margaret Wasserman In-Reply-To: <9CE47ECF-340C-4846-A053-C03F19EB9590@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 14:44:02 +0200 References: <200908071524.n77FONdo014337@givry.fdupont.fr> <1312CA4A-BB2F-4F7E-AC63-8BAEBA8AC682@sandstorm.net> <4688BD0B-0CF7-4B7C-9E5F-D12A41D4B295@net.t-labs.tu-berlin.de> <9CE47ECF-340C-4846-A053-C03F19EB9590@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Francis Dupont , ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 13:22:25 -0000 On Aug 11, 2009, at 14:23 , Margaret Wasserman wrote: > > On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote: >> >> If you want LISP on a desktop OS you need to update that OS, hence >> at the same time you can patch it to handle the 0 UDP checksum >> consequently. I do not see any real issue here. > > So, if I want LISP on a non-open-source desktop, you think I should > just wait until the OS vendor gives it to me? You have to wait only if you want the solution proposed by the vendor of the OS. > > Why is this any more reasonable than telling ISPs that if they want > to support LAG/ECMP for LISP flows, they need to buy new routers? > I did not claim that (or anything alike). Luigi > Margaret > From jnc@mercury.lcs.mit.edu Tue Aug 11 06:44:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B573A6FEF for ; Tue, 11 Aug 2009 06:44:49 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkzeJyU7SUnr for ; Tue, 11 Aug 2009 06:44:48 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4688C3A7118 for ; Tue, 11 Aug 2009 06:44:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C196F6BE557; Tue, 11 Aug 2009 09:43:28 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811134328.C196F6BE557@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 09:43:28 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 13:44:49 -0000 > From: Margaret Wasserman >> ii) unwrap it and discover that that EID is not at that ETR (which is >> a failure that can happen for other reasons, so has to be handled). > Will an error be sent back to the originating ITR when this happens, so > that it knows that it should try to update its mapping cache? I'm not sure if the behaviour for that case is specified yet (too lazy to look at the latest rev of the draft :-). I would definitely think an error message should be sent back from the ETR to the ITR. The ITR should, of course, make sure that any such error message is facially valid (i.e. that it has a mapping for that EID to that ETR), before taking any action on it. And that action should _not_ include dropping that ETR from the mapping, because that would introduce a DoS attack vector, since we still can't guarantee to have eradicated packets with bogus source addresses from the network as a whole. (And in any event, depending on that would be bad, as if someone clever figured out how to introduce them anyway, all security mechanisms built on that assumption would fail...) Having the bad ETR try and forward the packet is probably a waste of time; it will probably have to do a lookup cycle, and the results would only be useful for 1.4 RTTs, until the source ITR updates its mapping. But perhaps experience will show us otherwise...? >> The packet may arrive with a damaged source address. This may cause a >> bogus 'partner ITR' entry to be created (e.g. for the echo nonce >> entry), but I can't think of any real problems that will happen in >> this case. > Ummm... Wouldn't this cause end-nodes behind the destination ETR to be > unable to initiate connections to the original source EID until the > incorrect mapping is corrected? When I wrote that, I had forgotten about gleaning. As the later discussion on that topic (starting with my long reply to Sam's original long message) makes clear, that's probably not a major problem; as far as I can see we just have to be careful to document (and follow :-) the correct behaviour (never override a requested mapping, request a mapping to 'back up' any gleaned mappings as soon as you get the gleaned mapping, etc). > If this is a real issue, it is also a potential security problem, as > there is nothing preventing a node from sending a packet containing an > invalid EID/RLOC source pair, explicitly to create an incorrect mapping > entry. Yes (hence the "never override a requested mapping"). In general, scanning the spec carefully for DoS attack vectors is something else that needs to be done. We have paid a fair amount of attention to security, and many holes have been plugged, but there is always another one, of course.... > If the destination address is corrupted and the packet arrives at a > non-LISP node, that node will send back an ICMP "port unreachable" > message. We should make sure that the LISP node that receives the ICMP > error will handle it correctly -- in this case, just discard it. Yes. > In general, the LISP spec seems to lack information about how to > handle, and when to generate, ICMP errors. Good point. >> There are a _few_ functions which are piggybacked on user data >> traffic, and as alluded to in a prior message, we do have to be >> careful in designing them, to make sure they aren't affectable by >> damaged headers. So far that has been no problem. > When you say this has been no problem, do you mean in the experimental > LISP network? No, in the design process, as in 'no major problem to make sure that the protocol works in the presence of the occasional damaged, but undetected, packet'. E.g. with nonces, if every so often the return or reply value is bashed, or the bit is set the wrong way, things still work. > I'd be interested to know more about how that network is configured, so > that I could understand if it is likely to be representative of > real-world deployment in terms of these types of problems. Is there a > site that describes that network in detail? I know relatively little about the test network (although there's been a lot done over the last couple of years). There is this site: http://www.lisp4.net/ but other than that, someone else will have to provide any information about it you are interested in. Noel From hartmans@mit.edu Tue Aug 11 07:11:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0037A3A6F93; Tue, 11 Aug 2009 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+vPRNeF4V0r; Tue, 11 Aug 2009 07:11:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 3DB3F3A70E8; Tue, 11 Aug 2009 07:11:17 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4329551C7; Tue, 11 Aug 2009 10:09:25 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 11 Aug 2009 10:09:25 -0400 In-Reply-To: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 7 Aug 2009 15\:31\:11 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:11:18 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Francis Dupont the O UDP >> checksum proposal obsoletes all the today deployed nodes which >> check them (so all hosts I know and perhaps a lot of routers >> too) Noel> OK, so what are the other options for encapsulating a packet Noel> in a IPv6 packet? Noel> I'm told by some people that UDP-Lite isn't a standard yet? Noel> Or is it? (It seems to have a protocol number issued?) Does Noel> UDP-Lite work through NAT boxes? (LISP has a mobile-node Noel> mode, which we would like to see work through NAT boxes, so Noel> any proposed alternative solution has to work through NAT Noel> boxes too.) We have not reached a consensus that LISP needs to work through NATs. I'll take your message as a statement in favor of that and a personal opinion that they need to. I have not seen a lot of disagreement of this assumption, nor do I want to start that discussion now. I'm just trying to keep the mailing list history accurate to make my job as a chair easier when I have to turn this discussion into a conclusion. From hartmans@mit.edu Tue Aug 11 07:38:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EB93A7049 for ; Tue, 11 Aug 2009 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gug-f6no2h4k for ; Tue, 11 Aug 2009 07:38:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C0E1F3A7003 for ; Tue, 11 Aug 2009 07:38:05 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3267751C7; Tue, 11 Aug 2009 10:20:39 -0400 (EDT) To: Shane Amante References: <200908071524.n77FONdo014337@givry.fdupont.fr> <27109484-9BF9-4ED9-B40D-DCB96788B074@castlepoint.net> From: Sam Hartman Date: Tue, 11 Aug 2009 10:20:39 -0400 In-Reply-To: <27109484-9BF9-4ED9-B40D-DCB96788B074@castlepoint.net> (Shane Amante's message of "Fri\, 7 Aug 2009 11\:02\:11 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Francis Dupont , lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:38:06 -0000 >>>>> "Shane" == Shane Amante writes: >> - if we need to vary things between a pair of IPv6 xTRs it >> should be enough (and simple/easy) to vary the addresses Shane> The above was considered at the initial design stages of Shane> LISP, (I think Dino may have considered this approach?); Shane> however, it was shot down, because this would require the Shane> installers/administrators of the LISP ITR to both know the Shane> reasons why the above is required *and* configure the IPv6 Shane> ITR's with /64's to get the load-splitting benefits across Shane> LAG/ECMP paths. (Remember the adage: "My network, my Shane> rules"). Instead, it's more 'straightforward' to just have Shane> the ITR's / automatically/ calculate a hash of the incoming Shane> IP packet and stuff that into the UDP source port before Shane> transmitting it out its uplinks toward the ETR. The key Shane> advantage of this approach is that ITR's / will/ be owned & Shane> operated by downstream customer's (i.e.: it's their CE's) Shane> who are likely unaware of and, therefore, may not care Shane> about the (extremely large) prevalence of LAG/ECMP paths Shane> through their upstream providers ... until congestion Shane> occurs in their upstream providers and they get upset. Shane> When in doubt, automatic == good. Shane, I have not seen you very active on the LISP WG list before this discussion started. Even if this was considered during the initial phases of the LISP proposal, it has not been considered within the IETF context. It's entirely fine for the LISP WG to revisit discussions that happened before it formed. In general, we'll tend to give deference to those discussions if it's the same people discussing the same issue that were involved in the pre-IETF discussion. However this issue seems to be bringing in enough people from the wider community that it seems worth having again. That said, I've started what will become a consensus call in the LISP working group on what the LISP spec should say on this issue. So far no one has responded to that call supporting the option Francis proposed. So, while it would be entirely reasonable for us to consider that option even if it was previously discarded, we are not doing so. I really appreciate that you described why variations in source/dest address might be harder to deploy and why the deployment incentives may be wrong. I'd certainly encourage anyone bringing up this as a proposal to consider in response to my consensus call to respond to issues. Thanks for the great input, Sam Hartman LISP co-chair From hartmans@mit.edu Tue Aug 11 07:38:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAAA3A6EA0 for ; Tue, 11 Aug 2009 07:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSiGMb6yMpbN for ; Tue, 11 Aug 2009 07:38:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 813483A7037 for ; Tue, 11 Aug 2009 07:38:06 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A9E7F51C5; Tue, 11 Aug 2009 09:59:48 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 11 Aug 2009 09:59:48 -0400 In-Reply-To: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 7 Aug 2009 23\:13\:30 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:38:07 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Christopher Morrow While a >> non-lisp node receiving a LISP udp/0 packet dropping it seems >> fine to me, a translator dropping a udp/0|null-sum packet >> instead of translating it properly or telling the >> source-system: "oops, something bad happened" is unacceptable >> (in my mind). Noel> Ow; now you're making my head hurt. Noel> I don't think LISP was ever intended to work in the Noel> circumstance where an IPv[46] xTR was talking directly to an Noel> IPv[64] (i.e. the opposite of the other one) xTR, via a Noel> IPv[4-6] translator box - just like we don't expect IPv4 Noel> routers to talk to IPv6 routers through an IPv[4-6] Noel> translator box. As an individual, I'd like to rule it out of scope to make LISP work in this situation. From jnc@mercury.lcs.mit.edu Tue Aug 11 07:43:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF673A6AFA for ; Tue, 11 Aug 2009 07:43:08 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsxbLUi-OCb8 for ; Tue, 11 Aug 2009 07:43:08 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0A7E73A68DC for ; Tue, 11 Aug 2009 07:43:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3A30A6BE58F; Tue, 11 Aug 2009 10:41:16 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811144116.3A30A6BE58F@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 10:41:16 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:43:09 -0000 > From: Sam Hartman > I think you missed my primary point. .. Gleaning demonstrates that > packet corruption is more complicated than you originally thought. I > provided one example As I previously indicated, I agree that we do need to carefully audit the protocol for places where header damage (either LISP header, or IP header) on user-data packets could be an issue. (Just as we need to carefully audit it for DoS vectors.) As I also previously indicated, I had previously identified 'damage to unprotected headers' as an issue, and at the point that I did so, had done a cursory scan of the protocol (in my mind) to try and find problems (although I excepted the reachability bits, and didn't think them through in detail, because they might be replaced by versioning), and hadn't found any show-stoppers. I missed gleaning because I didn't realize it was still part of the spec. There may be others that I missed, also. That sort of careful sweep is not my forte, so I hope someone else will be looking at this? > this was by no means the only feature in LISP where I could not see > corruption being an issue. Can you provide details on what other cases/places concerned you? Noel From hartmans@mit.edu Tue Aug 11 07:46:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE443A7039 for ; Tue, 11 Aug 2009 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9KM5g7xsv7p for ; Tue, 11 Aug 2009 07:46:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7C7D33A6FE6 for ; Tue, 11 Aug 2009 07:46:52 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B7F71641DA; Tue, 11 Aug 2009 10:37:33 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 11 Aug 2009 10:37:33 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Injecting a bit of calm X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:46:54 -0000 Folks, the discussion has definitely produced a lot of interesting comments over the past couple of days. However in some instances it has been somewhat heated. When replying, please take a moment to consider things from the standpoint of the person you are replying to. If you feel that you simply disagree with someone, then that's fine; state your disagreement. We have different priorities and understandings; we may not always agree with each other. However if you are frustrated and feel that someone is not being reasonable, take a while to try and understand things from their standpoint before responding. Make sure your response is constructive and will help explore the disagreement. Questions about why someone thinks something are far better than assertions that they are being unreasonable or are ignoring some point of view. Ultimately if you think someone really is being unreasonable, talking to them in private, ignoring their message, and talking to the chairs are all better options than a message to the list. Thanks for your consideration, Sam Hartman LISP co-chair From jnc@mercury.lcs.mit.edu Tue Aug 11 07:51:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524B93A67ED for ; Tue, 11 Aug 2009 07:51:00 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0onGno0kcjAj for ; Tue, 11 Aug 2009 07:50:58 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4F6C43A682E for ; Tue, 11 Aug 2009 07:50:58 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 32C536BE58D; Tue, 11 Aug 2009 09:22:24 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811132224.32C536BE58D@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 09:22:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:51:00 -0000 {Hey, all, my mailbox was offline for a couple of days. Catching up now... So if it seems like I've missed a message, that would be why.} > From: Margaret Wasserman > what is it expected to do with packets destined to the source EID in > the meantime? In a short follow-up message to my long reply to Sam's long one pointing out this problem initially, I pointed out: >> Transient bogus mappings do no real harm - the choice would >> be between i) no mapping, and ii) a bad mapping. > PS: This thought applies to mappings gleaned from damaged packets, too. > If every so often one gets a bad mapping in the cache [from gleaning], > until the 'official' mapping comes through from the enquiry, [in spite > of that, gleaning]'s probably still a worthwhile optimization, because > i) no [additional] harm will have been done by the occasional bad > mapping, and ii) in all the other instances, one's better off than > waiting for the authenticated mapping to arrive. Was there a mistake somewhere in that line of reasoning? >> There is nothing in the spec that says *this is permitted*. > However, it does say that the use of "gleaned" mappings is allowed, and > places no specific limitations on their use. Can we distinguish between problems where i) the solution is relatively straightforward, and it more a case of 'make a note to document this in the next rev of the spec', and ii) where is a more serious technical issue, one which is not trivial? It does seem to me that this particular 'damaged header' issue falls into the former category. (Although I agree with what I perceive Sam's position to be, that we have to carefully audit the spec to make sure that any kind of damage to un-protected headers will not cause a problem.) Noel From hartmans@mit.edu Tue Aug 11 07:59:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C653A7026 for ; Tue, 11 Aug 2009 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvVvzhTAHOiW for ; Tue, 11 Aug 2009 07:59:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 9A4433A6F65 for ; Tue, 11 Aug 2009 07:58:55 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E388F51C8; Tue, 11 Aug 2009 10:26:35 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090807122736.266556BE55F@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 11 Aug 2009 10:26:35 -0400 In-Reply-To: <20090807122736.266556BE55F@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 7 Aug 2009 08\:27\:36 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 14:59:39 -0000 I think you missed my primary point. Gleaning is not the important issue. Gleaning demonstrates that packet corruption is more complicated than you originally thought. I provided one example, but this was by no means the only feature in LISP where I could not see corruption being an issue. From mrw@sandstorm.net Tue Aug 11 08:09:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC76D3A7026 for ; Tue, 11 Aug 2009 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD482qKCwvgF for ; Tue, 11 Aug 2009 08:09:40 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C97DC3A7027 for ; Tue, 11 Aug 2009 08:08:57 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BF7rvq007720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 11:07:53 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <83B45468-06A4-4BAE-983F-9DD4B4893E72@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:07:52 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:09:41 -0000 Hi Sam, On Aug 5, 2009, at 9:21 AM, Sam Hartman wrote: > so, we here in the LISP working group are faced with the question of > what should the LISP spec say while that discussion is ongoing. I'd > like to solicit opinions from this community about what goes in the > current LISP spec. Hopefully, the narrow consensus within LISP is > more clear so that we can focus on other things within this working > group. I think it may be a bit early for a formal consensus call on this topic, as people are still learning facts that are pertinent to this discussion, and some people are proposing additional solutions. Facts we are still learning include: How often does UDP packet corruption happen in real world deployments? The one fact we have (1 in ~7000 packets) seems consistent with the research papers I've seen on this topic. How do widely deployed systems deal with IPv4 UDP packets that use zero checksums? I've been told, for example, that recent Microsoft OSes (XP and Vista) will silently discard any IPv4 packets that they receive with a UDP checksum of zero, which is RFC-compliant behavior. I have asked some Microsoft folks to confirm this and will let the list know what I find out. I don't know if any other operating systems do the same. I have heard that there are firewalls that drop all IPv4 UDP packets with zero checksums. I don't even know who to ask about that... Are there any firewall vendors on this list who could comment? There is widely deployed hardware that will calculate and insert a valid UDP checksum in packets that are transmitted by the TCP/IP stack with zero UDP checksums. In some cases, it may not be practical (or desirable) to disable this functionality. There seem to be several NAT boxes that "correct" zero UDP checksums in packets that they forward, thus resulting in packets with bad non- zero checksums. To avoid problems with zero UDP checksums that are changed to non-zero values in transit, Dino has proposed that we hack the IP stack on every LISP-capable device to ignore all UDP checksums, not just zero ones. This is non-RFC compliant and is a second way in which the LISP spec would need to request a change to existing RFCs. It is not clear to me how/if a stack could be designed to do this _only_ for LISP packets, and not other types of packets tunneled in UDP/IP... > Here are options as I see them: > > 1) We can use 0 checksums with UDP, adding a normative reference to a > standards track document updating RFC 2460. Our spec will block > behind this standards track document and will move no faster than it > does. If the IETF chooses to go a different route, we will be faced > with having to make incompatible changes to LISP late in the process. > If that happens, individuals can come to the personal conclusion that > they are no longer interested in spending effort on the IETF LISP > spec, but they will not have the option of publishing a LISP spec > through the IETF that disagrees with IETF consensus. To support the current LISP specification, the standards track RFC you reference above would have to do two things: (1) allow the use of zero UDP checksums in IPv6, and (2) allow stacks to ignore non-zero UDP checksums (in both IPv4 and IPv6) on receipt. This is a fairly significant extension to Marshall's proposed document, and for me this is a non-starter. > 2) We can change LISP to use UDP-light. I would reluctantly support this choice, even though I understand that it would require IPv6 router updates to support UDP-Lite ports and/or the IPv6 flow label in their hash calculation. I consider it far better than the zero checksum alternative. In fact, I would prefer that we use UDP-Lite for both IPv4 and IPv6, and not use zero UDP checksums at all. > 3) We can make more significant changes to the LISP encapsulation. I prefer this choice. I'd like to see if we could come up with a solution _other than_ the use of UDP zero checksums that would work with the LAG/ECMP feature in legacy routers _and_ work on widely deployed host TCP/IP stacks without the need to modify the stack. Along these lines, I would like to understand why the idea of using different IIDs for different LISP flows for IPv6 was rejected. In fact, if we remove the "gleaning" feature from LISP, the source IPv4 address of the outer header could potentially be used for this purpose, as well. > I want to stress that if we choose option 1, the only way we will be > successful is if members of this community spend the necessary energy > in 6man and the IETF at large to build an IETF-wide consensus behind > the proposed change. No matter how strongly felt and unified feelings > are in the LISP working group, that alone will not make an IETF > consensus. I don't think there is any real chance of convincing the rest of the IETF that it is okay to ignore non-zero UDP checksums on receipt. So, I don't think this is a real option. Margaret From mrw@sandstorm.net Tue Aug 11 08:12:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C109B3A6FE9 for ; Tue, 11 Aug 2009 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdnqIK712Wat for ; Tue, 11 Aug 2009 08:12:18 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B142F3A67CC for ; Tue, 11 Aug 2009 08:12:17 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BFBBpO007942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 11:11:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <142DE1AD-6DDD-49FF-BA1D-27CA4AA001F7@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:11:11 -0400 References: <20090808031330.BB9726BE5CA@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:12:18 -0000 On Aug 11, 2009, at 9:59 AM, Sam Hartman wrote: > > Noel> I don't think LISP was ever intended to work in the > Noel> circumstance where an IPv[46] xTR was talking directly to an > Noel> IPv[64] (i.e. the opposite of the other one) xTR, via a > Noel> IPv[4-6] translator box - just like we don't expect IPv4 > Noel> routers to talk to IPv6 routers through an IPv[4-6] > Noel> translator box. > > As an individual, I'd like to rule it out of scope to make LISP work > in this situation. +1 Margaret From mrw@sandstorm.net Tue Aug 11 08:19:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCC63A6C83 for ; Tue, 11 Aug 2009 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vgGHmK-XBmA for ; Tue, 11 Aug 2009 08:19:39 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id EEE9F3A7067 for ; Tue, 11 Aug 2009 08:19:38 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BFIAf4008199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 11:18:10 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <10966FBD-BD65-458E-B6D2-F2F0ADE26349@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090811132224.32C536BE58D@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:18:09 -0400 References: <20090811132224.32C536BE58D@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Outer header damage [Re: Flow label redux] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:19:39 -0000 On Aug 11, 2009, at 9:22 AM, Noel Chiappa wrote: >> If every so often one gets a bad mapping in the cache [from >> gleaning], >> until the 'official' mapping comes through from the enquiry, [in >> spite >> of that, gleaning]'s probably still a worthwhile optimization, >> because >> i) no [additional] harm will have been done by the occasional bad >> mapping, and ii) in all the other instances, one's better off than >> waiting for the authenticated mapping to arrive. > > Was there a mistake somewhere in that line of reasoning? I'm thinking about this... I don't think there is a mistake in your reasoning if we only consider accidental corruption. There are security issues with "gleaned" mappings that may result in their removal from the specification. If that doesn't happen, then we need (IMO) to be very specific about how the gleaned mappings can be used and how/when they will be checked with the mapping system, etc. I agree with what you said about careful analysis of the specification to determine the impacts of corrupted outer headers. Margaret From dino@cisco.com Tue Aug 11 08:39:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5853A68A4; Tue, 11 Aug 2009 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0v4GOyLFgkz; Tue, 11 Aug 2009 08:39:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 308E23A6D9A; Tue, 11 Aug 2009 08:39:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPssgUqrR7O6/2dsb2JhbAC6YogrkCMFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="194462982" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2009 15:37:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7BFbROn026801; Tue, 11 Aug 2009 08:37:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7BFbRF9021811; Tue, 11 Aug 2009 15:37:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:37:26 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:37:24 -0700 Message-Id: <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 08:37:24 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 15:37:24.0752 (UTC) FILETIME=[9FD7D100:01CA1A99] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=976; t=1250005048; x=1250869048; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=JZZ89lhVWDAc5cSZrFg09b1wqyYWSnJEVLOgCI/G67o=; b=rVQ4GhyDdo47mY3Izuj5xxzR+hJME0AycMoTXUUIIqttzMXesBTn9LX27R pUq+ZalfeNDv65Nm6tJYRg/JUFWflrIlxiRzrXv536PCl8whzkVUTm5vzrOA tGAC2bYUuW; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:39:40 -0000 > On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >> >> The spec says ETRs MUST ignore the UDP checksum field. This is what >> the LISP authors intended and has been implemented this way. >> >> The spec says ITRs MUST set the UDP checksum field to 0. > > Could you tell us how to achieve this on commonly deployed desktop > software/hardware that has two properties: We don't want this rule on commonly deployed desktop hosts. Dino > - There is no means to turn off the checking of UDP checksums. They > will be checked if they are non-zero in IPv4, and they will be > checked in all cases in IPv6 with zero always being considered > invalid. > > - Networking Interface Cards that automatically calculate TCP/UDP > checksums on transmission if a checksum of zero is sent to the card. > > Systems with these properties are far more widely deployed than LAG/ > ECMP routers, and they are no easier/quicker to update. > > Margaret > From dino@cisco.com Tue Aug 11 08:44:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E813A6FF9 for ; Tue, 11 Aug 2009 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruAV4byYSy96 for ; Tue, 11 Aug 2009 08:44:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C479D3A677C for ; Tue, 11 Aug 2009 08:44:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOAugUqrR7PE/2dsb2JhbAC6U4grkCcFhBmBUWqHXA X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="182737459" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2009 15:43:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7BFhoL2023153; Tue, 11 Aug 2009 08:43:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7BFho22021932; Tue, 11 Aug 2009 15:43:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:43:50 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:43:50 -0700 Message-Id: <253DB2EA-D4C5-4B26-BCBF-D6A333DE6B63@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 08:43:49 -0700 References: <20090730202239.CE4016BE597@mercury.lcs.mit.edu> <193AB49B-E857-4C8F-A091-A329CFC74625@nokia.com> <54F0639D-A1EF-420B-9B14-EEC1CE77B212@cisco.com> <4AA28E27-1132-4C12-9FBE-898E9EB6DE90@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 15:43:50.0076 (UTC) FILETIME=[858397C0:01CA1A9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=741; t=1250005430; x=1250869430; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=+XK7CTlKcgLIU45Thdcyh0bWksgh/qGNUqeOPz57SK4=; b=Y+74z/HfhUT2kj02mE+2qeF+n5xT+Srtiwxulw0edqo1yQf9RtS+HOfJb5 i25Djv5w3El0TgZrOqC299Ols7B4AM1k0g+pKoYbRfGf54Aw6Ou/pkwNnGme Z/LEDzWAKa; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:44:48 -0000 I will make it more clear in the next rev of the spec. Dino On Aug 11, 2009, at 5:42 AM, Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > >>> 2) Document why you'd use UDP, not IPIP or udp-light. > Dino> This is already in the spec. > > You say that UDP is used for LAGs. I definitely didn't see a good > discussion of other options that were considered and rejected. > > It's my opinion as a chair that the issue must be documented. > > It's my opinion as an individual that the current documentation is > inadequate. Factors that lead to this conclusion include reading the > documentation and the amount of discussion this issue has generated > from people who have read the spec. From mrw@sandstorm.net Tue Aug 11 08:47:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533AC3A6AC9; Tue, 11 Aug 2009 08:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeSa+W7QCJOm; Tue, 11 Aug 2009 08:47:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 78B9D3A67FD; Tue, 11 Aug 2009 08:47:20 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BFiKss009164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 11:44:21 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:44:20 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:47:21 -0000 Hi Dino, On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote: >> On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >>> >>> The spec says ETRs MUST ignore the UDP checksum field. This is >>> what the LISP authors intended and has been implemented this way. >>> >>> The spec says ITRs MUST set the UDP checksum field to 0. >> >> Could you tell us how to achieve this on commonly deployed desktop >> software/hardware that has two properties: > > We don't want this rule on commonly deployed desktop hosts. I am not sure what you are saying here. I can think of two possibilities: (1) You don't want LISP to be implemented on commonly deployed desktop hosts. (2) You want to change the document to state a different rule, so that LISP can be implemented in a compliant manner on desktop hosts. Could you elaborate? Margaret From dino@cisco.com Tue Aug 11 08:49:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E3E3A67A2; Tue, 11 Aug 2009 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1hwknc6-NcZ; Tue, 11 Aug 2009 08:49:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BE5133A6A95; Tue, 11 Aug 2009 08:49:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABcvgUqrR7MV/2dsb2JhbAC6WYgrkCcFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="226411540" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2009 15:47:33 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7BFlWGl008379; Tue, 11 Aug 2009 08:47:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7BFlWV5003987; Tue, 11 Aug 2009 15:47:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:47:32 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:47:31 -0700 Message-Id: <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 08:47:31 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 15:47:32.0120 (UTC) FILETIME=[09DCD180:01CA1A9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=995; t=1250005652; x=1250869652; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=EBebLjdSl+c/kgVrGTvcb66ee0W7cm7TdxOUtUu/Tqg=; b=AkDKeSDH8GEp/VoC5iiBOuVvSWDr7xWW5/6t2FSun1wfFcfOaXyE4p2NrT RZt+WbvSsrv0mRG+RStaUaQoMgn58dC4QkzJeACtstzVjzMDMMW2J4VtVI7y zH+VgLsGZSgtTVRrX0XAbinxRYBAXIZnuesir5PZsDspFNLtYzBJQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 15:49:40 -0000 > Hi Dino, > > On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote: > >>> On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >>>> >>>> The spec says ETRs MUST ignore the UDP checksum field. This is >>>> what the LISP authors intended and has been implemented this way. >>>> >>>> The spec says ITRs MUST set the UDP checksum field to 0. >>> >>> Could you tell us how to achieve this on commonly deployed desktop >>> software/hardware that has two properties: >> >> We don't want this rule on commonly deployed desktop hosts. > > I am not sure what you are saying here. I can think of two > possibilities: > > (1) You don't want LISP to be implemented on commonly deployed > desktop hosts. Right, it is a network based solution. > (2) You want to change the document to state a different rule, so > that LISP can be implemented in a compliant manner on desktop hosts. That is not what I am suggesting. Dino > > Could you elaborate? > > Margaret > From jmh@joelhalpern.com Tue Aug 11 09:02:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685073A6FC5; Tue, 11 Aug 2009 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jSydcA0S81e; Tue, 11 Aug 2009 09:02:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A75BE3A69D6; Tue, 11 Aug 2009 09:02:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6306843031E; Tue, 11 Aug 2009 09:01:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4535A43031C; Tue, 11 Aug 2009 09:01:01 -0700 (PDT) Message-ID: <4A8195BC.5000709@joelhalpern.com> Date: Tue, 11 Aug 2009 12:01:00 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dino Farinacci References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> In-Reply-To: <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:02:35 -0000 Given that LISP ITRs work by intercepting packets that are not addressed to them, a host implementation would need to be able to intercept packets "in the stack". That is going to need some ability to modify kernel behavior. (Yes, I think we will see LISP enabled hosts. I don't think mobility is the only case where this will happen. But it will mean someone has modified the kernel to do so.) Yours, Joel Dino Farinacci wrote: >> Hi Dino, >> >> On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote: >> >>>> On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >>>>> >>>>> The spec says ETRs MUST ignore the UDP checksum field. This is what >>>>> the LISP authors intended and has been implemented this way. >>>>> >>>>> The spec says ITRs MUST set the UDP checksum field to 0. >>>> >>>> Could you tell us how to achieve this on commonly deployed desktop >>>> software/hardware that has two properties: >>> >>> We don't want this rule on commonly deployed desktop hosts. >> >> I am not sure what you are saying here. I can think of two >> possibilities: >> >> (1) You don't want LISP to be implemented on commonly deployed desktop >> hosts. > > Right, it is a network based solution. > >> (2) You want to change the document to state a different rule, so that >> LISP can be implemented in a compliant manner on desktop hosts. > > That is not what I am suggesting. > > Dino > >> >> Could you elaborate? >> >> Margaret >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Tue Aug 11 09:20:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16FC3A6774 for ; Tue, 11 Aug 2009 09:20:18 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rafHTZYpJWM8 for ; Tue, 11 Aug 2009 09:20:17 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B57153A68DE for ; Tue, 11 Aug 2009 09:20:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7157A6BE591; Tue, 11 Aug 2009 12:18:52 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 12:18:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:20:18 -0000 > From: Margaret Wasserman > I've been told, for example, that recent Microsoft OSes (XP and Vista) > will silently discard any IPv4 packets that they receive with a UDP > checksum of zero, which is RFC-compliant behavior. This is a bit of an aside, but.. if this is really IPv4/UDPv4 you're talking of, that is _most definitely_ *NOT* RFC-compliant. (And if you don't believe me, ask Dave Reed! :-) The spec says: "all zero transmitted checksum value means that the transmitter generated no checksum ... for higher level protocols that don't care". In other words, the OS _cannot_ know whether the higher-level application wants that field to be zero, or not, and it is a gross error for the OS to assume that it knows better than the application whether a packet with a zero in that field is acceptable or not. > I don't know if any other operating systems do the same. I would hope no other OS has made such an egregious error, one which is an elementary violation of the end-end principle. > I have heard that there are firewalls that drop all IPv4 UDP packets > with zero checksums. Ditto previous comment. > There is widely deployed hardware that will calculate and insert a > valid UDP checksum in packets that are transmitted by the TCP/IP stack > with zero UDP checksums. That's not necessarily a problem (e.g. it wouldn't be, for LISP). If something fast computes a checksum for one - hey, one can either use it, if one wishes, or ignore it, if one wishes; whatever floats one's boat. The only problem would be if something on the receiving end then either i) slowed down processing by checking the checksum, even though it was not used, or ii) (worse) discarded packets which had a bad checksum, _even if_ the application didn't want the checksums (e.g. packet voice). > There seem to be several NAT boxes that "correct" zero UDP checksums in > packets that they forward, thus resulting in packets with bad non- zero > checksums. > To avoid problems with zero UDP checksums that are changed to non-zero > values in transit, Dino has proposed that we hack the IP stack on every > LISP-capable device to ignore all UDP checksums, not just zero ones. > This is non-RFC compliant Let's not forget that this is basically caused by the existence of boxes that do non-compliant stuff, i.e. tweak zero-checksums to be non-zero. In other words, this is just trying to deal pragmatically with the fact that there is stuff out there that does the wrong thing. Extending this principle, there's probably no perfect solution, because no matter what you do, there's probably _some_ stuff out there that's busted. E.g. if we use UDP-Lite, there are probably deployed NAT boxes that don't forward it, etc, etc. Saying 'a LISP xTR has to do this non-standard thing' is probably the best of the evils, because at least that is 'sort of' under the control of the person doing the xTR - whereas stuff in the middle that does the wrong thing is something the xTRs have no control over. > It is not clear to me how/if a stack could be designed to do this > _only_ for LISP packets, and not other types of packets tunneled in > UDP/IP... The problem is that in checking the UDP checksum _on behalf of the application_, the OS is trying to do too much, and violating the end-end principle in the process. It can't even checksum packets which _appear_ to have a checksum (not checking only those with a zero checksum). Consider the following case: A packet is sent with a zero checksum, and is damaged in transit - _in the checkum field_. That packet is still fine, as far as the application is concerned, and for the OS to discard it is erroneous. Sure, not all applications want to have to check checksums, so the UDP interface should provide two ways to receive packets: UDP_receive_only_good_packets(), and UDP_receive_any_old_packet(). And yes, the UDPv4 spec is severely under-written. A different age, ya know? It could probably use a re-write to make the seemingly obvious, well, explicit. >> 3) We can make more significant changes to the LISP encapsulation. > I prefer this choice. ... Along these lines, I would like to understand > why the idea of using different IIDs for different LISP flows for IPv6 > was rejected. What about IPv4? And any proposed new solution would have to work through deployed IPv4 NAT boxes, which rules out a new protocol. (And no, we aren't going to encapsulate LISP in HTTP... :-) > I don't think there is any real chance of convincing the rest of the > IETF that it is okay to ignore non-zero UDP checksums on receipt. So, I > don't think this is a real option. If so, that means we're effectively back to my suggestion of a week or two ago: leave encapsulation _in_ IPv6 (as opposed to _of_ IPv6) out of the spec altogether. Noel From jmh@joelhalpern.com Tue Aug 11 09:22:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56F33A6B91; Tue, 11 Aug 2009 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uBF9alAEiv9; Tue, 11 Aug 2009 09:22:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 481F43A6774; Tue, 11 Aug 2009 09:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5C27A430346; Tue, 11 Aug 2009 09:20:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 69F1F43033B; Tue, 11 Aug 2009 09:20:23 -0700 (PDT) Message-ID: <4A819A46.9080801@joelhalpern.com> Date: Tue, 11 Aug 2009 12:20:22 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dino Farinacci References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <58CCF81A-4581-4D04-A76D-AF52E454BF62@cisco.com> In-Reply-To: <58CCF81A-4581-4D04-A76D-AF52E454BF62@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:22:15 -0000 I believe that saying "ITRs don't receiving packets." is a linguistic step that only confuses people. ITRs receive unencapsulated packets from the site, and encapsulate them in LISP headers (assuming mappings are already available.) Now, one can argue that the ITR function in the router does not "receive" packets, since it was the router that received the packet. (One can even argue that the router "intercepted" the packet rather than "received" it.) But functionally it is the same thing. Yours, Joel Dino Farinacci wrote: >> Given that LISP ITRs work by intercepting packets that are not >> addressed to them, a host implementation would need to be able to >> intercept packets "in the stack". That is going to need some ability >> to modify kernel behavior. > > (1) ITRs don't receive packets. They encapsulate packets. From dino@cisco.com Tue Aug 11 09:23:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC663A6774; Tue, 11 Aug 2009 09:23:18 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG0WA0PiCAQj; Tue, 11 Aug 2009 09:23:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3C3C03A70E5; Tue, 11 Aug 2009 09:23:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPM0gUqrR7MV/2dsb2JhbAC6bogrkCwFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="226426489" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2009 16:10:18 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7BGAJtH029934; Tue, 11 Aug 2009 09:10:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7BGAJKs003071; Tue, 11 Aug 2009 16:10:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:10:19 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:10:18 -0700 Message-Id: <58CCF81A-4581-4D04-A76D-AF52E454BF62@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A8195BC.5000709@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 09:10:18 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 16:10:18.0770 (UTC) FILETIME=[38730F20:01CA1A9E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3096; t=1250007019; x=1250871019; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=yvdjA3PbwI7sPAQuN4O9NcbAt+5UhyYD3YLadytcB7Y=; b=H/yVbiHAjQoKWrz+WwYcpQUej0aOGOm/oglRQxRhwCzCR4Sg/medpLjH9i xQoIisisAbcSWpsPdaUry6UP8pTQRJpuGL6M5fzSl5ToQZVZgU5XVgiVYDjn 2QzGeI+Jd3+2U0n24mjojquYXguf0zsBgsgaDLjvGWWSc3FUzVRPw=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:23:18 -0000 > Given that LISP ITRs work by intercepting packets that are not > addressed to them, a host implementation would need to be able to > intercept packets "in the stack". That is going to need some > ability to modify kernel behavior. (1) ITRs don't receive packets. They encapsulate packets. (2) ETRs receive encapsulated packets addressed to one of their RLOC addresses. (3) For Map-Requests, there are 3 forms: i. Encapsulated Map-Requests which are originated by the map- server the ETR is registered to and is addressed to the ETR. ii. Map-Requests which are addressed to EIDs but are traveled over the ALT. Only when an ETR is attached to the ALT (not a standard configuration recommendation), that it must process a packet that is not addressed to it. But this is a packet destined to port 4342 and not 4341. UDP port 4342 is the control port. iii. Data Probes (which is not default and probably will be deprecated behavior) are addressed to EIDs which ETRs must intercept. They are addressed to UDP port 4341. Data Probes can be sent on the underlying network (LISP variant 1) or sent on the ALT which means the requirements in ii must be adhered to. > (Yes, I think we will see LISP enabled hosts. I don't think > mobility is the only case where this will happen. But it will mean > someone has modified the kernel to do so.) I would not recommend it and I believe won't be accepted for the same reasons that shim6 wasn't accepted. You will use locator aggregatability for EID-prefixes if you do. The mapping database will be unnecessarily large. IMHO, a non-starter. Where you can aggregate EIDs, you should. In a roaming case where you may not be able to, then you don't. Dino > > Yours, > Joel > > > Dino Farinacci wrote: >>> Hi Dino, >>> >>> On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote: >>> >>>>> On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >>>>>> >>>>>> The spec says ETRs MUST ignore the UDP checksum field. This is >>>>>> what the LISP authors intended and has been implemented this way. >>>>>> >>>>>> The spec says ITRs MUST set the UDP checksum field to 0. >>>>> >>>>> Could you tell us how to achieve this on commonly deployed >>>>> desktop software/hardware that has two properties: >>>> >>>> We don't want this rule on commonly deployed desktop hosts. >>> >>> I am not sure what you are saying here. I can think of two >>> possibilities: >>> >>> (1) You don't want LISP to be implemented on commonly deployed >>> desktop hosts. >> Right, it is a network based solution. >>> (2) You want to change the document to state a different rule, so >>> that LISP can be implemented in a compliant manner on desktop hosts. >> That is not what I am suggesting. >> Dino >>> >>> Could you elaborate? >>> >>> Margaret >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Tue Aug 11 09:39:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F65C3A7022; Tue, 11 Aug 2009 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxQZKWEYnZ99; Tue, 11 Aug 2009 09:39:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id CEFAE3A69DD; Tue, 11 Aug 2009 09:39:49 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A933C51C6; Tue, 11 Aug 2009 12:38:45 -0400 (EDT) To: "Joel M. Halpern" References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> From: Sam Hartman Date: Tue, 11 Aug 2009 12:38:45 -0400 In-Reply-To: <4A8195BC.5000709@joelhalpern.com> (Joel M. Halpern's message of "Tue\, 11 Aug 2009 12\:01\:00 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:39:50 -0000 Joel> Given that LISP ITRs work by intercepting packets that are Joel> not addressed to them, a host implementation would need to Joel> be able to intercept packets "in the stack". That is going Joel> to need some ability to modify kernel behavior. I'm trying to figure out how an ITR does anything different than a router with a tunneled interface. Every host I'm aware of has a facility for setting up an interface that routes some set of packets--including potentially the default route--through a tunnel interface that then passes the packet to userspace for processing. From dino@cisco.com Tue Aug 11 09:44:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA803A70B4; Tue, 11 Aug 2009 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoulZM4803Sr; Tue, 11 Aug 2009 09:44:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 274C93A710A; Tue, 11 Aug 2009 09:44:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK48gUqrR7MV/2dsb2JhbAC6fogrkC4FhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="365166732" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2009 16:42:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7BGgjJH003895; Tue, 11 Aug 2009 09:42:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BGgjQi021638; Tue, 11 Aug 2009 16:42:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:42:44 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:42:44 -0700 Message-Id: <34EC732C-EDF4-4093-B1AA-163C16BBCA15@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A819A46.9080801@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 09:42:44 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <58CCF81A-4581-4D04-A76D-AF52E454BF62@cisco.com> <4A819A46.9080801@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 16:42:44.0546 (UTC) FILETIME=[C038EA20:01CA1AA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1433; t=1250008965; x=1250872965; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=Y8MJnf1ntxss+TJHW1/Pvu7aATj5Oj7+ebi6uO9Nk0E=; b=JmhoHo0pwN5aOkk9PjfHVl3HxdUGuZDh/dTHKSnwdteEJxt3fURF+z8ctE Fv4zz/cipBUgKWHt599voKNd4lFMHquWFgFGF62TKWyaSaV8DSbyt159SFVp QJLtnGzKiOpgyYkfymXCl8JbPMAlz3QhgmrlMn7GLX+GKIji/Y0Qs=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:44:44 -0000 > I believe that saying "ITRs don't receiving packets." is a > linguistic step that only confuses people. You are right, but your text wasn't clear if the packets were coming from the site or from the core. So I assumed you were referring to the Map-Request or Data-Probe case. > ITRs receive unencapsulated packets from the site, and encapsulate > them in LISP headers (assuming Right, just like any router does today. > mappings are already available.) Now, one can argue that the ITR > function in the router does not "receive" packets, since it was the > router that received the packet. (One can even argue that the > router "intercepted" the packet rather than "received" it.) But > functionally it is the same thing. I am not following you, but don't bother to explain. You are making a subtle point about forwarding versus consuming packets? Where an ETR would consume an encapsulated packet because its addressed to itself and when an ITR receives packets from site hosts, that it is forwarding? Dino > > Yours, > Joel > > > Dino Farinacci wrote: >>> Given that LISP ITRs work by intercepting packets that are not >>> addressed to them, a host implementation would need to be able to >>> intercept packets "in the stack". That is going to need some >>> ability to modify kernel behavior. >> (1) ITRs don't receive packets. They encapsulate packets. From jmh@joelhalpern.com Tue Aug 11 09:45:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880B23A6A95; Tue, 11 Aug 2009 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bALzgf-gbwY; Tue, 11 Aug 2009 09:45:27 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AF9EF3A710B; Tue, 11 Aug 2009 09:45:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C309243031E; Tue, 11 Aug 2009 09:44:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A5DE1430320; Tue, 11 Aug 2009 09:44:11 -0700 (PDT) Message-ID: <4A819FDA.5010702@joelhalpern.com> Date: Tue, 11 Aug 2009 12:44:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Sam Hartman References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:45:28 -0000 Maybe I was missing a bet. You would have to direct all the packets from the host back to user space to be processed, since it is only the LISP logic that can decide whether the packet should be tunneled or not. But if they support that concept, then it can be done. And yes, that does seem to mean that if we could use the UDP stack right out of the box, then this would require no kernel modifications to add it. Which is a nice benefit. Given what has been discussed, this leads me to looking more closely at using the IPv6 flowID to enable load balacning, and not using UDP at all. However, I do not know how to make this work with the deployed boxes that do hardware ECMP / LAG in the field already for IPv6. Yours, Joel Sam Hartman wrote: > Joel> Given that LISP ITRs work by intercepting packets that are > Joel> not addressed to them, a host implementation would need to > Joel> be able to intercept packets "in the stack". That is going > Joel> to need some ability to modify kernel behavior. > > I'm trying to figure out how an ITR does anything different than a > router with a tunneled interface. > > Every host I'm aware of has a facility for setting up an interface > that routes some set of packets--including potentially the default > route--through a tunnel interface that then passes the packet to > userspace for processing. > > From dino@cisco.com Tue Aug 11 09:47:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AD73A6F3F; Tue, 11 Aug 2009 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ncpvh-F36mj; Tue, 11 Aug 2009 09:47:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1E1923A6DCD; Tue, 11 Aug 2009 09:47:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANs9gUqrR7O6/2dsb2JhbAC7EIgrkCwFhBmBUYhG X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="365169228" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2009 16:46:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7BGkGVK021428; Tue, 11 Aug 2009 09:46:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BGkGV8025760; Tue, 11 Aug 2009 16:46:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:46:16 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:46:16 -0700 Message-Id: <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 09:46:14 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 16:46:16.0329 (UTC) FILETIME=[3E746F90:01CA1AA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1276; t=1250009179; x=1250873179; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=NQsSDiIizwKaMsoWfxA+TijAKrjwMEA+KbMSgzPgabE=; b=ntmSDJOqs+UCmiHRdJamxh7M1pyqJiOBBixmh9WQQd8KUYZ66L7XInVIyD LS8Y2DnTX6IalAM3zvTFO6fNrfIHn3Nrd/kmK6ObA8MR+SbUdaf0Ccwb+XxW dUcRKY7ajq; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:47:43 -0000 > Joel> Given that LISP ITRs work by intercepting packets that are > Joel> not addressed to them, a host implementation would need to > Joel> be able to intercept packets "in the stack". That is going > Joel> to need some ability to modify kernel behavior. > > I'm trying to figure out how an ITR does anything different than a > router with a tunneled interface. It doesn't. I mean there are subtleties about if a map-cache entry exists and what to do when it doesn't. But if a map-cache entry exists it is similar to a packet arriving on an interface and is sent on a GRE tunnel. There are implementation details that make it different, but from a conceptual level, they are the same. > Every host I'm aware of has a facility for setting up an interface > that routes some set of packets--including potentially the default > route--through a tunnel interface that then passes the packet to > userspace for processing. We call "LISP tunnels" as "dynamic encapsulating tunnels" where an implementation must not implement the tunnel as a logical interface. The implementation cannot scale if it does this. You get the level of indirection by doing another lookup in another data structure called the "map-cache". Dino From mrw@sandstorm.net Tue Aug 11 09:50:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54003A6FF0 for ; Tue, 11 Aug 2009 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBua0lP0qsV0 for ; Tue, 11 Aug 2009 09:50:51 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 823C03A6EBD for ; Tue, 11 Aug 2009 09:50:45 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BGl8nH012141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 12:47:09 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 12:47:08 -0400 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:50:52 -0000 On Aug 11, 2009, at 12:18 PM, Noel Chiappa wrote: > >> There is widely deployed hardware that will calculate and insert a >> valid UDP checksum in packets that are transmitted by the TCP/IP >> stack >> with zero UDP checksums. > > That's not necessarily a problem (e.g. it wouldn't be, for LISP). If > something fast computes a checksum for one - hey, one can either use > it, if > one wishes, or ignore it, if one wishes; whatever floats one's boat. > > The only problem would be if something on the receiving end then > either i) > slowed down processing by checking the checksum, even though it was > not used, > or ii) (worse) discarded packets which had a bad checksum, _even if_ > the > application didn't want the checksums (e.g. packet voice). As written, the LISP spec says: "UDP Checksum: this field MUST be transmitted as 0 and ignored on receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. For performance reasons, the ETR MUST ignore the checksum and MUST not do a checksum computation." This wording would make a LISP ITR that does send a non-zero checksum non-compliant, and an ETR that checks non-zero checksums non-compliant. Your paragraph above would be more reasonably translated as "UDP Checksum: this field MAY be transmitted as 0, and MAY be ignored on receipt by the ETR". So, what you are saying above does not seem to agree with the current LISP specification. If we changed the MUSTs in the spec to MAYs, one could implement a compliant (although perhaps not highly performing) LISP ITR or ETR on a standard TCP/IP stack, even if I couldn't stop it from computing outbound UDP checksums or checking inbound ones. IMO, this would be substantial improvement. However, the "MAY" wording still wouldn't be compliant with RFC 1122 (Requirements for Internet Hosts) or RFC 2460 (IPv6). RFC 1122 requires that all TCP/IP stacks support UDP checksums in both direction, and that they check all non-zero checksums on receipt. So, to say "the ETR MUST ignore the checksum" (or even "the ETR MAY ignore the checksum") in an IETF document, we would need to get a standards track document approved that updates _both_ RFC 1122 and RFC 2460. If we want to boil this down to the (relatively simpler and more tractable) question of getting a document approved that allows zero UDP checksums in IPv6, we could change this wording to say: "UDP Checksums: this field MAY be transmitted as 0 [normative reference to document that makes this okay in IPv6]. Note, even when the UDP checksum is transmitted as 0, an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non- zero. To address this concern, LISP ITRs SHOULD be capable of calculating UDP checksums on encapsulated packets." Alternatively, you could state that LISP won't work through NAT boxes with this property, perhaps in a middlebox considerations section. If you want LISP to actually _be_ RFC compliant, and not to potentially lag behind standards-track RFC updates, you could simply indicate that this field contains a valid UDP checksum value (MAY be zero for IPv4, MUST NOT be zero for IPv6). Since there are checksum offload chips that can calculate a UDP checksum very quickly, it should be possible to build LISP hardware that does calculate UDP checksums at the necessary level of performance. This last choice, which I will summarize as "be RFC 1122 and 2460 compliant", would include checksum protection for the IPv6 header _AND_ would support LAG/ECMP, at the cost of requiring that LISP systems (which are the new thing we are building) be capable of calculating checksums. I think this may be the best trade-off available, although I understand that it isn't cost-free. Margaret From dino@cisco.com Tue Aug 11 09:56:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556483A70B5; Tue, 11 Aug 2009 09:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt2auKHQ0UiN; Tue, 11 Aug 2009 09:56:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2CE353A6FB5; Tue, 11 Aug 2009 09:56:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALs/gUqrR7PD/2dsb2JhbAC7DogrkC0FhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="194502652" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2009 16:55:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7BGtLjc012921; Tue, 11 Aug 2009 09:55:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BGtLRE006730; Tue, 11 Aug 2009 16:55:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:55:21 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 09:55:20 -0700 Message-Id: <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 09:55:19 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 16:55:20.0646 (UTC) FILETIME=[82E49E60:01CA1AA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4605; t=1250009721; x=1250873721; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=rZJQpPaX3fkTlvhfi8t022gUYaq1sAM1CwH2S62g9pI=; b=W+VRyKO45kwo6F77tSwcNWK9yQNRcnHn/boX+yONCN6t50zdWudCuVzenZ aHcHD+rgYbfhlSVI8nlnFteIS+JPcJmLQfMDPL4fIk9dKxGdzY5SpeSU+kKK w1BpZhD+zL; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ipv6@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 16:56:38 -0000 Copying ipv6@ietf.org for a question. If we changed the text in the LISP draft from "MUST" to "MAY", would we still need to write the accompanying document to RFC 2460? Maybe Lars can comment on this. See below for details. Dino On Aug 11, 2009, at 9:47 AM, Margaret Wasserman wrote: > > On Aug 11, 2009, at 12:18 PM, Noel Chiappa wrote: >> >>> There is widely deployed hardware that will calculate and insert a >>> valid UDP checksum in packets that are transmitted by the TCP/IP >>> stack >>> with zero UDP checksums. >> >> That's not necessarily a problem (e.g. it wouldn't be, for LISP). If >> something fast computes a checksum for one - hey, one can either >> use it, if >> one wishes, or ignore it, if one wishes; whatever floats one's boat. >> >> The only problem would be if something on the receiving end then >> either i) >> slowed down processing by checking the checksum, even though it was >> not used, >> or ii) (worse) discarded packets which had a bad checksum, _even >> if_ the >> application didn't want the checksums (e.g. packet voice). > > As written, the LISP spec says: > > "UDP Checksum: this field MUST be transmitted as 0 and ignored on > receipt by the ETR. Note, even when the UDP checksum is transmitted > as 0 an intervening NAT device can recalculate the checksum and > rewrite the UDP checksum field to non-zero. For performance reasons, > the ETR MUST ignore the checksum and MUST not do a checksum > computation." > > This wording would make a LISP ITR that does send a non-zero > checksum non-compliant, and an ETR that checks non-zero checksums > non-compliant. > > Your paragraph above would be more reasonably translated as "UDP > Checksum: this field MAY be transmitted as 0, and MAY be ignored on > receipt by the ETR". So, what you are saying above does not seem to > agree with the current LISP specification. > > If we changed the MUSTs in the spec to MAYs, one could implement a > compliant (although perhaps not highly performing) LISP ITR or ETR > on a standard TCP/IP stack, even if I couldn't stop it from > computing outbound UDP checksums or checking inbound ones. IMO, > this would be substantial improvement. > > However, the "MAY" wording still wouldn't be compliant with RFC 1122 > (Requirements for Internet Hosts) or RFC 2460 (IPv6). > > RFC 1122 requires that all TCP/IP stacks support UDP checksums in > both direction, and that they check all non-zero checksums on > receipt. So, to say "the ETR MUST ignore the checksum" (or even > "the ETR MAY ignore the checksum") in an IETF document, we would > need to get a standards track document approved that updates _both_ > RFC 1122 and RFC 2460. > > If we want to boil this down to the (relatively simpler and more > tractable) question of getting a document approved that allows zero > UDP checksums in IPv6, we could change this wording to say: > > "UDP Checksums: this field MAY be transmitted as 0 [normative > reference to document that makes this okay in IPv6]. Note, even > when the UDP checksum is transmitted as 0, an intervening NAT device > can recalculate the checksum and rewrite the UDP checksum field to > non-zero. To address this concern, LISP ITRs SHOULD be capable of > calculating UDP checksums on encapsulated packets." Alternatively, > you could state that LISP won't work through NAT boxes with this > property, perhaps in a middlebox considerations section. > > If you want LISP to actually _be_ RFC compliant, and not to > potentially lag behind standards-track RFC updates, you could simply > indicate that this field contains a valid UDP checksum value (MAY be > zero for IPv4, MUST NOT be zero for IPv6). Since there are checksum > offload chips that can calculate a UDP checksum very quickly, it > should be possible to build LISP hardware that does calculate UDP > checksums at the necessary level of performance. > > This last choice, which I will summarize as "be RFC 1122 and 2460 > compliant", would include checksum protection for the IPv6 header > _AND_ would support LAG/ECMP, at the cost of requiring that LISP > systems (which are the new thing we are building) be capable of > calculating checksums. I think this may be the best trade-off > available, although I understand that it isn't cost-free. > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Tue Aug 11 10:19:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDBE3A67BE; Tue, 11 Aug 2009 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGNramgswUnF; Tue, 11 Aug 2009 10:19:56 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 837773A6B63; Tue, 11 Aug 2009 10:19:05 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id DB08D701BA9C; Tue, 11 Aug 2009 19:18:16 +0200 (CEST) Message-Id: <1EDE9780-517E-40D8-842F-35857527CC2F@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Joel M. Halpern In-Reply-To: <4A8195BC.5000709@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 19:18:16 +0200 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 17:19:57 -0000 On Aug 11, 2009, at 18:01 , Joel M. Halpern wrote: > Given that LISP ITRs work by intercepting packets that are not > addressed to them, a host implementation would need to be able to > intercept packets "in the stack". That is going to need some > ability to modify kernel behavior. > We already did it for FreeBSD. (http://inl.info.ucl.ac.be/softwares/openlisp ) The latest version (not yet publicly available) supports IPv6, and yes it ignores the checksum (will be changed if the WG reaches a different consensus). This is possible in OpenLISP since we capture the packet at IP level, before actually forwarding it to the UDP level. The same applies for outgoing packets. They are captured at IP level just before the routing table lookup. This allows to encap (if necessary) no matter if the packet is coming from the upper layers or from the forwarding module. Luigi > (Yes, I think we will see LISP enabled hosts. I don't think > mobility is the only case where this will happen. But it will mean > someone has modified the kernel to do so.) > > Yours, > Joel > > > Dino Farinacci wrote: >>> Hi Dino, >>> >>> On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote: >>> >>>>> On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote: >>>>>> >>>>>> The spec says ETRs MUST ignore the UDP checksum field. This is >>>>>> what the LISP authors intended and has been implemented this way. >>>>>> >>>>>> The spec says ITRs MUST set the UDP checksum field to 0. >>>>> >>>>> Could you tell us how to achieve this on commonly deployed >>>>> desktop software/hardware that has two properties: >>>> >>>> We don't want this rule on commonly deployed desktop hosts. >>> >>> I am not sure what you are saying here. I can think of two >>> possibilities: >>> >>> (1) You don't want LISP to be implemented on commonly deployed >>> desktop hosts. >> Right, it is a network based solution. >>> (2) You want to change the document to state a different rule, so >>> that LISP can be implemented in a compliant manner on desktop hosts. >> That is not what I am suggesting. >> Dino >>> >>> Could you elaborate? >>> >>> Margaret >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Tue Aug 11 10:19:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23A33A6B11 for ; Tue, 11 Aug 2009 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os3U2xIwGB+x for ; Tue, 11 Aug 2009 10:19:57 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id D75373A6B40 for ; Tue, 11 Aug 2009 10:19:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 712EFA38D9 for ; Tue, 11 Aug 2009 10:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5EDE543031E; Tue, 11 Aug 2009 10:13:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 46FA3430309; Tue, 11 Aug 2009 10:13:45 -0700 (PDT) Message-ID: <4A81A6C8.1000802@joelhalpern.com> Date: Tue, 11 Aug 2009 13:13:44 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Margaret Wasserman References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> In-Reply-To: <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 17:19:58 -0000 Requiring hardware modification of routers in order to support LISP with reasonable performance does not seem a good choice. The problem is that if we try to make all this fit together we end up with: May transmit UDP checksum as 0. Note that while the RFCs require the non-zero UDP checksums be verified, it is likely that many implementations will not implement this step in the processing. Which is some pretty ugly text to put in an RFC, but is what the real world will likely do no matter what we require. Yours, Joel Margaret Wasserman wrote: > > On Aug 11, 2009, at 12:18 PM, Noel Chiappa wrote: >> >>> There is widely deployed hardware that will calculate and insert a >>> valid UDP checksum in packets that are transmitted by the TCP/IP stack >>> with zero UDP checksums. >> >> That's not necessarily a problem (e.g. it wouldn't be, for LISP). If >> something fast computes a checksum for one - hey, one can either use >> it, if >> one wishes, or ignore it, if one wishes; whatever floats one's boat. >> >> The only problem would be if something on the receiving end then >> either i) >> slowed down processing by checking the checksum, even though it was >> not used, >> or ii) (worse) discarded packets which had a bad checksum, _even if_ the >> application didn't want the checksums (e.g. packet voice). > > As written, the LISP spec says: > > "UDP Checksum: this field MUST be transmitted as 0 and ignored on > receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 > an intervening NAT device can recalculate the checksum and rewrite the > UDP checksum field to non-zero. For performance reasons, the ETR MUST > ignore the checksum and MUST not do a checksum computation." > > This wording would make a LISP ITR that does send a non-zero checksum > non-compliant, and an ETR that checks non-zero checksums non-compliant. > > Your paragraph above would be more reasonably translated as "UDP > Checksum: this field MAY be transmitted as 0, and MAY be ignored on > receipt by the ETR". So, what you are saying above does not seem to > agree with the current LISP specification. > > If we changed the MUSTs in the spec to MAYs, one could implement a > compliant (although perhaps not highly performing) LISP ITR or ETR on a > standard TCP/IP stack, even if I couldn't stop it from computing > outbound UDP checksums or checking inbound ones. IMO, this would be > substantial improvement. > > However, the "MAY" wording still wouldn't be compliant with RFC 1122 > (Requirements for Internet Hosts) or RFC 2460 (IPv6). > > RFC 1122 requires that all TCP/IP stacks support UDP checksums in both > direction, and that they check all non-zero checksums on receipt. So, > to say "the ETR MUST ignore the checksum" (or even "the ETR MAY ignore > the checksum") in an IETF document, we would need to get a standards > track document approved that updates _both_ RFC 1122 and RFC 2460. > > If we want to boil this down to the (relatively simpler and more > tractable) question of getting a document approved that allows zero UDP > checksums in IPv6, we could change this wording to say: > > "UDP Checksums: this field MAY be transmitted as 0 [normative reference > to document that makes this okay in IPv6]. Note, even when the UDP > checksum is transmitted as 0, an intervening NAT device can recalculate > the checksum and rewrite the UDP checksum field to non-zero. To address > this concern, LISP ITRs SHOULD be capable of calculating UDP checksums > on encapsulated packets." Alternatively, you could state that LISP > won't work through NAT boxes with this property, perhaps in a middlebox > considerations section. > > If you want LISP to actually _be_ RFC compliant, and not to potentially > lag behind standards-track RFC updates, you could simply indicate that > this field contains a valid UDP checksum value (MAY be zero for IPv4, > MUST NOT be zero for IPv6). Since there are checksum offload chips that > can calculate a UDP checksum very quickly, it should be possible to > build LISP hardware that does calculate UDP checksums at the necessary > level of performance. > > This last choice, which I will summarize as "be RFC 1122 and 2460 > compliant", would include checksum protection for the IPv6 header _AND_ > would support LAG/ECMP, at the cost of requiring that LISP systems > (which are the new thing we are building) be capable of calculating > checksums. I think this may be the best trade-off available, although I > understand that it isn't cost-free. > > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From darlewis@cisco.com Tue Aug 11 10:27:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94BD3A6AC6; Tue, 11 Aug 2009 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWOP0lWCVu8c; Tue, 11 Aug 2009 10:27:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0655E3A6A2F; Tue, 11 Aug 2009 10:27:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEtGgUqrR7PD/2dsb2JhbAC7AIgrkDMFhBk X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="182777243" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2009 17:25:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7BHPvIJ019587; Tue, 11 Aug 2009 10:25:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7BHPvlG026467; Tue, 11 Aug 2009 17:25:57 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 10:25:56 -0700 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: Tue, 11 Aug 2009 10:25:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Judging Consensus on the UDP Checksum Issue Thread-Index: Acoap04pyk+Yds2KT0uQOTwKNCBYzAAATmyw References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu><928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net><32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> From: "Darrel Lewis (darlewis)" To: "Fred Baker (fred)" , "Dino Farinacci (dino)" X-OriginalArrivalTime: 11 Aug 2009 17:25:56.0930 (UTC) FILETIME=[C9675220:01CA1AA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=741; t=1250011557; x=1250875557; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=TNF5O/XGn9PtRlRkh88Soaec2E0iup9ocGztnv+gMD0=; b=DRgN2mBvA1OJtprXDfpN+vQFA63tcIQgLVJfanj9SO6eXRm797JE7uCk8p Q8g/X8queAocCguivwVJ3k12JjHJBbgviHHPZ6XkjvXOF4iEY4CXRZykFK3r 2M77TnYzRq; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Margaret Wasserman , ipv6@ietf.org, lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 17:27:10 -0000 > > "UDP Checksum: this field MUST be transmitted as 0 and ignored on =20 > > receipt by the ETR. Note, even when the UDP checksum is=20 > transmitted =20 > > as 0 an intervening NAT device can recalculate the checksum and =20 > > rewrite the UDP checksum field to non-zero. For performance=20 > reasons, =20 > > the ETR MUST ignore the checksum and MUST not do a checksum =20 > > computation." >=20 > I would expect a NAT that saw a zero value to not recalculate the =20 > checksum. >=20 Fred, We found this not to be the case in our testing of LISP. Many commercial (netgear and linksys being two that come to mind) NATs do indeed recalculate the checksum regardless of its initial value. =20 Regards, -Darrel From mrw@sandstorm.net Tue Aug 11 10:50:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123323A69BA; Tue, 11 Aug 2009 10:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtNx5Nc4SYKt; Tue, 11 Aug 2009 10:50:26 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id F31973A68DA; Tue, 11 Aug 2009 10:50:25 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BHmFUC014815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 13:48:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 13:48:16 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 17:50:27 -0000 On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote: > >> Every host I'm aware of has a facility for setting up an interface >> that routes some set of packets--including potentially the default >> route--through a tunnel interface that then passes the packet to >> userspace for processing. > > We call "LISP tunnels" as "dynamic encapsulating tunnels" where an > implementation must not implement the tunnel as a logical interface. > The implementation cannot scale if it does this. You get the level > of indirection by doing another lookup in another data structure > called the "map-cache". I don't think I understand this... Why couldn't LISP be implemented as a logical interface that encapsulates or not based on the contents of the LISP Mapping cache and the results of mapping lookups? Margaret From dino@cisco.com Tue Aug 11 11:07:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47C93A68BA; Tue, 11 Aug 2009 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ0gv2eAKgUT; Tue, 11 Aug 2009 11:07:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F3C6D3A6ACE; Tue, 11 Aug 2009 11:07:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACNQgUqrR7PE/2dsb2JhbAC6fogrkDoFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="194538189" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2009 18:05:07 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7BI57dD022414; Tue, 11 Aug 2009 11:05:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7BI57mH023674; Tue, 11 Aug 2009 18:05:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:05:07 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:05:06 -0700 Message-Id: <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:05:06 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 18:05:07.0024 (UTC) FILETIME=[422B3500:01CA1AAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1154; t=1250013907; x=1250877907; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=VHpkeueM8HFiwminWshNors6Fem3rPmIzQEOd9COGXk=; b=etQLNHgZ3wPtbL5uLtVTn6ix/FZ5m/nKktguWmtVGjA6YlMiWLlhkwBGrn Hl1QY1mqcudJ0268C+MF1xDOIjL9nxZFcC2SKNlSgz3k8oI+SFSWoVf114dr 7PguPECDVE; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:07:14 -0000 > On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote: >> >>> Every host I'm aware of has a facility for setting up an interface >>> that routes some set of packets--including potentially the default >>> route--through a tunnel interface that then passes the packet to >>> userspace for processing. >> >> We call "LISP tunnels" as "dynamic encapsulating tunnels" where an >> implementation must not implement the tunnel as a logical >> interface. The implementation cannot scale if it does this. You get >> the level of indirection by doing another lookup in another data >> structure called the "map-cache". > > I don't think I understand this... > > Why couldn't LISP be implemented as a logical interface that > encapsulates or not based on the contents of the LISP Mapping cache > and the results of mapping lookups? Because you could have 100K of them. Interface data structures come with all kinds of other stuff that doesn't apply here. And guess what if you had 100K map-cache entries, the number of logical interfaces is equal to the sum of all locators for all 100K entries. Dino > > Margaret > From hartmans@mit.edu Tue Aug 11 11:21:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FD63A6A79; Tue, 11 Aug 2009 11:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4EzoKmNfaF4; Tue, 11 Aug 2009 11:21:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 5901B3A68BA; Tue, 11 Aug 2009 11:21:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F40FA51C5; Tue, 11 Aug 2009 14:18:56 -0400 (EDT) To: Dino Farinacci References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> From: Sam Hartman Date: Tue, 11 Aug 2009 14:18:56 -0400 In-Reply-To: <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> (Dino Farinacci's message of "Tue\, 11 Aug 2009 09\:46\:14 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:21:27 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> We call "LISP tunnels" as "dynamic encapsulating tunnels" Dino> where an implementation must not implement the tunnel as a Dino> logical interface. The implementation cannot scale if it Dino> does this. You get the level of indirection by doing another Dino> lookup in another data structure called the "map-cache". I see no text in draft-ietf-lisp-03 that says that lisp tunnels cannot be logical interfaces and would object strongly to including such an implementation detail in the spec. I see text that says that they must not be statically configured. I also don't see the scaling argument you're making. Perhaps you're trying to say is that you want all traffic considered for lisp encapsulation and do not want to flood the mapping database into the local routing table. That's probably true, but seems quite unrelated to whether something is a logical interface at least with several host routing implementations I'm familiar with. From dino@cisco.com Tue Aug 11 11:26:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CFA3A68DA; Tue, 11 Aug 2009 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldO9-+8uJfrD; Tue, 11 Aug 2009 11:26:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D64FE3A6B43; Tue, 11 Aug 2009 11:26:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB5UgUqrR7O6/2dsb2JhbAC7AIgrkD4FhBmBUYhG X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="365244885" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2009 18:25:53 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7BIPrdr018453; Tue, 11 Aug 2009 11:25:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7BIPrLW003919; Tue, 11 Aug 2009 18:25:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:25:53 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:25:52 -0700 Message-Id: <49F25063-D004-43CD-BC3A-993534E9004D@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:25:52 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 18:25:52.0827 (UTC) FILETIME=[28B9A8B0:01CA1AB1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1461; t=1250015153; x=1250879153; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=Lw6AFhiA7yKJtP1oD+1hmvESRESMCNAsSu0E44cAN4U=; b=Ll28dXsWeRcKZKOJIM3xVrRcr2QfYRvobyUendUCWPyruvAExA5gkTX8yn 1f4fLiyR/BQX8lSNZxr78cHYi4m7CusZGNtCGow3EwF12TQqVkiwxMPrYa5b p0wK54NUpY; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:26:47 -0000 >>>>>> "Dino" == Dino Farinacci writes: > > Dino> We call "LISP tunnels" as "dynamic encapsulating tunnels" > Dino> where an implementation must not implement the tunnel as a > Dino> logical interface. The implementation cannot scale if it > Dino> does this. You get the level of indirection by doing another > Dino> lookup in another data structure called the "map-cache". > > I see no text in draft-ietf-lisp-03 that says that lisp tunnels cannot > be logical interfaces and would object strongly to including such an > implementation detail in the spec. I see text that says that they > must not be statically configured. Because it is an implementation issue. If an ITR decided to encapsulate all its packets to a recursive encapsulator, it could build an implementation with a single logical interface. > I also don't see the scaling argument you're making. Perhaps you're > trying to say is that you want all traffic considered for lisp > encapsulation and do not want to flood the mapping database into the > local routing table. That's probably true, but seems quite unrelated > to whether something is a logical interface at least with several host > routing implementations I'm familiar with. This is all implementation dependent. You can talk to dozens if not 100s of IOS engineers about this next time you are in an IETF hallway. They will talk your ear off. ;-) Dino From mrw@sandstorm.net Tue Aug 11 11:30:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220773A6A2F; Tue, 11 Aug 2009 11:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDRXuT9C+3fp; Tue, 11 Aug 2009 11:29:59 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 745A13A6EDA; Tue, 11 Aug 2009 11:29:54 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BISwfT016882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 14:28:58 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 14:28:57 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:30:00 -0000 Hi Dino, On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote: >> Why couldn't LISP be implemented as a logical interface that >> encapsulates or not based on the contents of the LISP Mapping cache >> and the results of mapping lookups? > > Because you could have 100K of them. Interface data structures come > with all kinds of other stuff that doesn't apply here. And guess > what if you had 100K map-cache entries, the number of logical > interfaces is equal to the sum of all locators for all 100K entries. I was talking about running an ITR as a logical interface on a LISP- aware end-node or a home gateway, so I'm not talking about something that would need to scale to handle 100K simultaneous connections. This could be done in a way that _didn't_ involve a logical interface per map-cache entry, by having the code in the logical interface "driver" maintain and access the map-cache. Margaret From luigi@net.t-labs.tu-berlin.de Tue Aug 11 11:36:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921213A6A2F; Tue, 11 Aug 2009 11:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyJybgKjV0pd; Tue, 11 Aug 2009 11:36:56 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 86D8D3A69BA; Tue, 11 Aug 2009 11:36:56 -0700 (PDT) Received: from [192.168.2.101] (p4FC24BFC.dip.t-dialin.net [79.194.75.252]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id E6DB8701BA9C; Tue, 11 Aug 2009 20:35:58 +0200 (CEST) Message-Id: From: Luigi Iannone To: Dino Farinacci In-Reply-To: <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 20:35:58 +0200 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:36:57 -0000 On Aug 11, 2009, at 20:05 , Dino Farinacci wrote: >> On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote: >>> >>>> Every host I'm aware of has a facility for setting up an interface >>>> that routes some set of packets--including potentially the default >>>> route--through a tunnel interface that then passes the packet to >>>> userspace for processing. >>> >>> We call "LISP tunnels" as "dynamic encapsulating tunnels" where an >>> implementation must not implement the tunnel as a logical >>> interface. The implementation cannot scale if it does this. You >>> get the level of indirection by doing another lookup in another >>> data structure called the "map-cache". >> >> I don't think I understand this... >> >> Why couldn't LISP be implemented as a logical interface that >> encapsulates or not based on the contents of the LISP Mapping cache >> and the results of mapping lookups? > > Because you could have 100K of them. Interface data structures come > with all kinds of other stuff that doesn't apply here. And guess > what if you had 100K map-cache entries, the number of logical > interfaces is equal to the sum of all locators for all 100K entries. I fully support Dino. When we started to implement LISP, our first choice was to create a new logical interface, but we soon realized that it will never work. Luigi > > Dino > >> >> Margaret >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Aug 11 11:47:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA683A6B79; Tue, 11 Aug 2009 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFZ1bbDJkVXQ; Tue, 11 Aug 2009 11:47:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 797783A6783; Tue, 11 Aug 2009 11:47:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEZZgUqrR7PD/2dsb2JhbAC7B4grkEAFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="226521298" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2009 18:45:46 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7BIjkkg030341; Tue, 11 Aug 2009 11:45:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7BIjkv7015750; Tue, 11 Aug 2009 18:45:46 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:45:46 -0700 Received: from [192.168.1.3] ([10.21.67.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 11:45:45 -0700 Message-Id: <8D8080B4-0821-464C-84B3-2891CF67ECCF@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 11:45:45 -0700 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 18:45:46.0093 (UTC) FILETIME=[EFF799D0:01CA1AB3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1243; t=1250016346; x=1250880346; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=95vqfEIzzlb+44nriT30Q5JbALbfh8mkH0E0GQpHiXE=; b=RDwqaesuZoUfx6gIZGJZ/SDL3H783oZI21l1nuyxWLKrta41GXwZ/QrG6r GmkNJn9sf1NlRJs4BHrL37rE8pZh077ssw3CotRmRfj9QwXr1t6gkWJENdoU kM0XpF3+Ts; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:47:34 -0000 I think this is off topic. If you want to continue the discussion, send me email privately. > Hi Dino, > > On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote: >>> Why couldn't LISP be implemented as a logical interface that >>> encapsulates or not based on the contents of the LISP Mapping >>> cache and the results of mapping lookups? >> >> Because you could have 100K of them. Interface data structures come >> with all kinds of other stuff that doesn't apply here. And guess >> what if you had 100K map-cache entries, the number of logical >> interfaces is equal to the sum of all locators for all 100K entries. > > I was talking about running an ITR as a logical interface on a LISP- > aware end-node or a home gateway, so I'm not talking about something > that would need to scale to handle 100K simultaneous connections. Doesn't matter. You can still talk to 100s or 1000s of places, meaning you'd have a map-cache that large. > This could be done in a way that _didn't_ involve a logical > interface per map-cache entry, by having the code in the logical > interface "driver" maintain and access the map-cache. Sure, you are using the logical interface for a different reason. Dino From mrw@sandstorm.net Tue Aug 11 11:58:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892633A6917; Tue, 11 Aug 2009 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR+MgoFI0NRz; Tue, 11 Aug 2009 11:58:07 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 991CD3A635F; Tue, 11 Aug 2009 11:58:07 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BIuPgA017947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 14:56:26 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3C922FC4-32E6-4CA8-88B2-3D74A73C4DD9@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <8D8080B4-0821-464C-84B3-2891CF67ECCF@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 14:56:25 -0400 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> <8! D8080B4-0821-464C-84B3-2891CF67ECCF@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 18:58:08 -0000 On Aug 11, 2009, at 2:45 PM, Dino Farinacci wrote: >> I was talking about running an ITR as a logical interface on a LISP- >> aware end-node or a home gateway, so I'm not talking about >> something that would need to scale to handle 100K simultaneous >> connections. > > Doesn't matter. You can still talk to 100s or 1000s of places, > meaning you'd have a map-cache that large. Or not. The whole point of a cache is that it is an optimization... I don't connect to more than a couple of dozen hosts regularly, and I certainly don't connect to more than a few hundred hosts in the course of a few minutes. So, I could be pretty happy with a cache that had a few thousand entries. I'd just have to do a mapping lookup if my destination EID wasn't one of the last (or most frequent, depending on my cache aging algorithm) few thousand EIDs I'd visited. I'm not arguing that this model would work for all ITRs. Obviously if my ISP (Verizon) deploys an ITR that has to handle all of the hosts in Massachusetts, it will need to be _considerably_ more capable than my Mac or Windows PC. I'd just like to make sure we also define something that can scale down to desktop PCs and to low cost home routers, etc. Margaret From luigi@net.t-labs.tu-berlin.de Tue Aug 11 12:12:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541C93A6FDF; Tue, 11 Aug 2009 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjhysXBtA+DJ; Tue, 11 Aug 2009 12:12:25 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 4F08B3A6B05; Tue, 11 Aug 2009 12:12:25 -0700 (PDT) Received: from [192.168.2.101] (p4FC24BFC.dip.t-dialin.net [79.194.75.252]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 91E76701BA9C; Tue, 11 Aug 2009 20:41:20 +0200 (CEST) Message-Id: <2E282E43-B60F-4871-8586-7BAFE4ECD9D9@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Margaret Wasserman In-Reply-To: <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 20:41:19 +0200 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 19:12:26 -0000 On Aug 11, 2009, at 20:28 , Margaret Wasserman wrote: > > Hi Dino, > > On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote: >>> Why couldn't LISP be implemented as a logical interface that >>> encapsulates or not based on the contents of the LISP Mapping >>> cache and the results of mapping lookups? >> >> Because you could have 100K of them. Interface data structures come >> with all kinds of other stuff that doesn't apply here. And guess >> what if you had 100K map-cache entries, the number of logical >> interfaces is equal to the sum of all locators for all 100K entries. > > I was talking about running an ITR as a logical interface on a LISP- > aware end-node or a home gateway, so I'm not talking about something > that would need to scale to handle 100K simultaneous connections. > > This could be done in a way that _didn't_ involve a logical > interface per map-cache entry, Yes you can do that. _But_ this means that your routing table has to include entries in order to "route" the packet to the logical interface in order to be encapsulated. I do not think this will help to solve the scalability issue. Luigi > by having the code in the logical interface "driver" maintain and > access the map-cache. > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Tue Aug 11 12:50:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B162F3A6879; Tue, 11 Aug 2009 12:50:18 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1mhR1H1VHE5; Tue, 11 Aug 2009 12:50:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C150B3A68FF; Tue, 11 Aug 2009 12:50:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJJngUqrR7MV/2dsb2JhbAC7bYgrkEEFhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="194584821" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2009 19:49:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7BJnKlc027469; Tue, 11 Aug 2009 12:49:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7BJnKEv008869; Tue, 11 Aug 2009 19:49:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 12:49:20 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 12:49:19 -0700 Message-Id: <38E8BA63-648D-41FD-ABC2-2FD440D601B5@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <3C922FC4-32E6-4CA8-88B2-3D74A73C4DD9@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 12:49:19 -0700 X-OriginalArrivalTime: 11 Aug 2009 19:49:20.0102 (UTC) FILETIME=[D14B3060:01CA1ABC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1681; t=1250020160; x=1250884160; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20IPv6=20UDP=20checksum=20issue |Sender:=20; bh=YaYTDnCZKVmlzEGM7v6gDo/lKCUZIPnQOyoiewCAOdc=; b=A/k+UTM5tEMYTFcgsGU0OrmlkYUd3bOfWOeP1+iPAFSHjY9+M8Sb6Ug2ux b9U2cpILSjW/8weuhex+kzzdXzuZnd9F0bict4te4yUXbbAGw/xiUEN5/64O h5M5KabXtfnBKXFXuqTcVRF61Hfglldo1obiGz3hWzH6JTzZJwX3o=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "ipv6@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] IPv6 UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 19:50:18 -0000 References: <0E71FC61-5A42-4C5A-A22A-69B3213A9EBA@nokia.com> <9A49FB30-3293-4681-86FD-0ABF7CD60994@nokia.com> <4A76101E.7070207@gmail.com> <5CB1D2DE-14A8-4549-A9CE-90FD56043174@cisco.com> <1DCFF91C-5DC8-4F67-8316-A7D763C1E261@sandstorm.net> <9EEEFEBB-3F1B-4B30-88BE-8C2814D8CE52@cisco.com> <20E7DD15-3168-4054-B296-AD725F68B444@sandstorm.net> <200ABCA5-7016-481F-BF9B-309591FCA44E@cisco.com> <4A8195BC.5000709@joelhalpern.com> <9E345E12-A236-4B1C-B5B5-CE6D21258981@cisco.com> <879016E5-701B-4AA7-852A-59727DF9B560@cisco.com> <03166A50-6693-4979-A548-67BD33279E69@sandstorm.net> <8! D8080B4-0821-464C-84B3-2891CF67ECCF@cisco.com> <3C922FC4-32E6-4CA8-88B2-3D74A73C4DD9@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Return-Path: dino@cisco.com X-OriginalArrivalTime: 11 Aug 2009 19:49:19.0854 (UTC) FILETIME=[D12558E0:01CA1ABC] > I'm not arguing that this model would work for all ITRs. Obviously > if my ISP (Verizon) deploys an ITR that has to handle all of the > hosts in Massachusetts, it will need to be _considerably_ more > capable than my Mac or Windows PC. I'd just like to make sure we > also define something that can scale down to desktop PCs and to low > cost home routers, etc. We are. There is nothing prohibiting this usage. Dino From hartmans@mit.edu Tue Aug 11 13:15:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF1D3A6B92 for ; Tue, 11 Aug 2009 13:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyyo04iEMl6B for ; Tue, 11 Aug 2009 13:15:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6F4753A6906 for ; Tue, 11 Aug 2009 13:15:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0B10D51C8; Tue, 11 Aug 2009 16:13:26 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 11 Aug 2009 16:13:26 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:15:32 -0000 Currently draft-ietf-lisp-ms describes the use of RFC 2402 H with MD5 preshared keys as the mandatory to implement mechanism between an ETR and a map server . This mechanism fails to meet IETF security requirements in the following ways: * RFC 4107 (a BCP) requires that in many cases automated key management be used. If that analysis is followed, it is clear that a number of LISP map servers will need to have automated key management so we must provide that. * MD5 is probably not appropriate hash in our usage as a new protocol. Algorithm agility--the ability to change and negotiate hash algorithms is definitely required. * RFC 4301 moves AH from a MUST to MAY implement feature of IPsec. Using ESP in null mode (no encryption) would be more correct if we use IPsec. * IPSec is not a good fit for this application. If we're going to use IPsec we need to follow the recommendations of the BCP for using IPsec in other protocols. That includes things like specifying what SPD entries are expected and fitting our use of IPsec to RFC 2401. * RFC 2401 and 2402 have been obsoleted by a new and somewhat different IPsec model. From mrw@lilacglade.org Tue Aug 11 13:25:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A853A67D3 for ; Tue, 11 Aug 2009 13:25:23 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ5bOwXR3LmM for ; Tue, 11 Aug 2009 13:25:22 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 6ED383A6B79 for ; Tue, 11 Aug 2009 13:25:22 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id T1Jb1c0011GXsucA58QnuQ; Tue, 11 Aug 2009 20:24:47 +0000 Received: from lilac.sandstorm.net ([69.33.111.74]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id T8Qd1c00N1cMU3H8T8QhHK; Tue, 11 Aug 2009 20:24:45 +0000 Message-Id: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> From: Margaret Wasserman To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 16:24:36 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:25:23 -0000 I believe that (at least) seven separate issues have been raised in the thread(s) about zero UDP checksums that should be added to the LISP tracker, so that we can track their resolution. These are all issues regarding text in document version -03. #1: Sending UDP Zero Checksums Violates RFC 2460 The use of zero UDP checksums in IPv6 is forbidden by RFC 2460. This issue could be addressed in one of two ways: (1) move to any standards-compliant encapsulation, or (2) include a normative reference to a standards-track document that updates RFC 2460 to allow UDP zero checksums. #2: Sending UDP Zero Checksums not Universally Implemented Current TCP/IP stacks do not always implement the ability to turn off UDP checksum calculation for outbound traffic. In some cases, this could be corrected by a software change. In other cases, the checksum may be calculated in hardware. It may not be possible to turn off UDP checksum calculation for outbound LISP traffic, without turning off UDP checksum calculation for all outbound traffic. This issue could be resolved by changing the text that indicates that LISP ITRs "MUST" send zero UDP checksums to a "MAY". #3: Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 and RFC 2460 Not checking non-zero UDP checksums on inbound traffic (at the ETR in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6). There is concern that checking the checksums would cause two problems: performance issues for existing routers that lacks the ability to perform the checksum efficiently, and problems when the zero UDP checksums themselves are corrupted en route (particularly by poorly implemented NAT boxes). This issue could be addressed in one of two ways: (1) require standards-compliant behavior in LISP ETRs, or include a normative reference to a standards-track RFC that updates RFC 1122 and RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums. #4: Not Checking Inbound Non-Zero Checksums not Universally Implemented. There are TCP/IP stacks that do not have any way to turn off checking of non-zero UDP checksums on receipt. If this functionality can be turned off, it may not be possible to turn it off for LISP traffic only , while it remains enabled for other traffic. Also, the checksum may be checked in hardware before the software sees the packet. This issue could be resolved by changing the text that indicates that LISP ETRs "MUST" ignore incoming UDP checksums to a "MAY". #5: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis Research (the Stone/Partridge paper) and prior experience (with NFS and IS-IS, among others) have indicated that it is (at least sometimes) a very bad idea to disable and/or bypass UDP or IP checksums. References: Stone/Partridge Paper on Internet Checksums: http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm IS-IS Optional Checksum: http://www.rfc-editor.org/rfc/rfc3358.txt We have proposed disabling the IPv4 UDP checksum and effectively disabling both the IPv6 header and UDP checksum in IPv6. As part of making this decision in a responsible manner, we need to perform (and document) an analysis of the implications of that choice, both on LISP itself and on other nodes and applications that have to co-exist with LISP. #6: LAG/ECMP Requirements Not Well-Explained The LAC/ECMP requirements that drive some LISP design choices are not well-explained in the draft. This issue was raised by Sam Hartman, and Dino agreed to add additional text. #7: Limits on "Gleaned" Map Entries Not Clear The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail. Document editors, could you please add these issues to the LISP tracker, so that we can keep track of their resolutions? Thanks, Margaret From hartmans@mit.edu Tue Aug 11 13:25:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702943A6B10 for ; Tue, 11 Aug 2009 13:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpSozQCGHYA4 for ; Tue, 11 Aug 2009 13:25:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id B451D3A6917 for ; Tue, 11 Aug 2009 13:25:44 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F183351C8; Tue, 11 Aug 2009 16:25:06 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 11 Aug 2009 16:25:06 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:25:45 -0000 Currently, the interface between the ITR and map resolver has two security concerns. * There is no integrity protection of the exchange between the ITR and map resolver * An ITR accepts a reply from any ETR, which makes it hard to add security. The only protection of the map reply is that it needs to have the same nonce as the map request. Long term, that is unlikely to be good enough. It will be impossible to provide protection against on-path attackers who can observe the nonce unless cryptographic security is used. I understand that the alt does not currently provide cryptographic security. I don't know whether we'll conclude that is adequate (although suspect we'll decide it's the best we can do for the experimental version). However even if that is adequate, it seems like in many deployments the path between the ITR and map resolver is more open to attack than the path over the alt. For this reason I suspect that cryptographic security is needed to the map resolver even if it is not provided in the alt. If others disagree, I'm happy to hold this issue open until we've actually done security analysis of the ITR map resolver security. I'm not comfortable closing this issue before that analysis. If cryptographic security is provided between the ITR and map resolver, it must meet the same requirements as security between the ETR and map server. From mrw@sandstorm.net Tue Aug 11 13:27:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D22C3A6F3F for ; Tue, 11 Aug 2009 13:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75u43FkeH5k9 for ; Tue, 11 Aug 2009 13:27:02 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 635AF3A6F2A for ; Tue, 11 Aug 2009 13:27:02 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BKQbqD021820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 16:26:37 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <4A97E2C4-056C-4CC9-8B1D-AB7FEED268DF@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 16:26:37 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:27:03 -0000 Hi Sam, On Aug 11, 2009, at 4:13 PM, Sam Hartman wrote: > > * RFC 2401 and 2402 have been obsoleted by a new and somewhat > different IPsec model. Where is the new model documented? Thanks, Margaret From hartmans@mit.edu Tue Aug 11 13:31:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAB33A6FA2 for ; Tue, 11 Aug 2009 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quw5oZUObbLG for ; Tue, 11 Aug 2009 13:31:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 59AE53A6F7E for ; Tue, 11 Aug 2009 13:31:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 23E1651C8; Tue, 11 Aug 2009 16:30:57 -0400 (EDT) To: Sam Hartman References: From: Sam Hartman Date: Tue, 11 Aug 2009 16:30:57 -0400 In-Reply-To: (Sam Hartman's message of "Tue\, 11 Aug 2009 16\:13\:26 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:31:35 -0000 Speaking very much as an individual. I think the right way to secure ETR->MS is to use TLS over a TCP connection. I've heard the arguments about why IPsec and TLS are inappropriate for BGP and I agree to a very large extent with these arguments. However I don't think they apply to a map server. You definitely should not time out a registration simply because a TCP connection goes down, so the fake RST issue will be hugely less of a big deal than with BGP. If you still care about RST issues, then use TCP AO+TLS keyed by the TLS extractor. Using TLS does not imply several things: * It does not imply a PKI: self-signed certificates or even preshared keys can be used. * It does not imply encrypting everything: TLS supports integrity only mode. * You can implement TLS on a router. You probably already do. I may have missed something that makes TLS inappropriate but if I have it's something relatively non-obvious; a message of the form "this is a non starter," will be remarkably unconvincing. From hartmans@mit.edu Tue Aug 11 13:37:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC433A6F7E for ; Tue, 11 Aug 2009 13:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1WpZLrZ6GB5 for ; Tue, 11 Aug 2009 13:37:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7740C3A6B5D for ; Tue, 11 Aug 2009 13:37:32 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2846851C6; Tue, 11 Aug 2009 15:59:13 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 11 Aug 2009 15:59:13 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Issue tracking--policy on wiki, let's start! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:37:34 -0000 Margaret asked me why we weren't following the issue tracking guidelines we had agreed to. i looked and realized the dropped ball was in my court. I've now posted the agreed policy at http://tools.ietf.org/wg/lisp/trac/wiki/IssueTracking I think Margaret will be writing issues she believes have been raised in this discussion to be tracked. From dino@cisco.com Tue Aug 11 13:38:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65823A7027 for ; Tue, 11 Aug 2009 13:38:39 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRBRorMb60Xu for ; Tue, 11 Aug 2009 13:38:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 15CEE3A702F for ; Tue, 11 Aug 2009 13:38:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGlzgUqrR7PE/2dsb2JhbAC7SogrkEgFhBmKFw X-IronPort-AV: E=Sophos;i="4.43,362,1246838400"; d="scan'208";a="365339804" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2009 20:37:39 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7BKbdkm018032; Tue, 11 Aug 2009 13:37:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BKba3K014838; Tue, 11 Aug 2009 20:37:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:37:38 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:37:38 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 13:37:38 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 20:37:38.0337 (UTC) FILETIME=[90C6C110:01CA1AC3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=438; t=1250023059; x=1250887059; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20management=20and=20security=2 0mechanism |Sender:=20; bh=DK+fSv3JkkHjSyBfC6xL4RMubfymJJ/1mM+Y4AQMrho=; b=nR58fUiKfLiw9nUOIyJ3WhTurT8ynONqEhD1ES2kIdzH+z3T94PGSWLY2E IBiWCrxXQNwAG2IIJ1upvbVxvOFXWcRq0GJIVr/CyupvtMi5JQrw8cdbIYDv eLiNdmICpM; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:38:40 -0000 > I think the right way to secure ETR->MS is to use TLS over a TCP > connection. I've heard the arguments about why IPsec and TLS are > inappropriate for BGP and I agree to a very large extent with these > arguments. And what are the reasons you think TLS over TCP is inappropriate for BGP? Don't forget the map-server must support up to 1000s of registered sites. We chose a soft state solution so it can scale. Dino From dino@cisco.com Tue Aug 11 13:41:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68513A6B5D for ; Tue, 11 Aug 2009 13:41:10 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF2+FBb1FRjd for ; Tue, 11 Aug 2009 13:41:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 27D073A6906 for ; Tue, 11 Aug 2009 13:41:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO5xgUqrR7PD/2dsb2JhbAC7VYgrkEgFhBmKFw X-IronPort-AV: E=Sophos;i="4.43,362,1246838400"; d="scan'208";a="226585339" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2009 20:32:22 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7BKWMvx027475; Tue, 11 Aug 2009 13:32:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7BKWMei026043; Tue, 11 Aug 2009 20:32:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:32:22 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:32:22 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 13:32:22 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 20:32:22.0143 (UTC) FILETIME=[D44F60F0:01CA1AC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=860; t=1250022742; x=1250886742; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#3]=20lisp-ms=20needs=20secur ity=20between=20ITR=20and=20map=20resolver |Sender:=20; bh=JhmZaBCWcJiztzoOcdCXEL0Co9kKdTCo7hqocb4eiaI=; b=pd0Wsd7XIfqlmFBi1bEnS/z5puEIy3P49/2ptYeXzq7HdrfZb5swDxWt3N ZNcDK4FnlVts97KQy9ZAiKi6LYOru730gS/xne9uxkxQeYi1l7UreXys0+tG snj/T+i5X0; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:41:11 -0000 > If others disagree, I'm happy to hold this issue open until we've > actually done security analysis of the ITR map resolver security. I'm > not comfortable closing this issue before that analysis. I disagree of course. If we build all this machinery, what you might be suggesting, into these protocols, they will never get deployed. The LISP authors have stated that man-in-the-middle attacks on infrastructure components are unlikely to occur so we believe they are not problems. We made a judgement call so we can actually build a usable architecture that can be deployed quickly and soon. > If cryptographic security is provided between the ITR and map > resolver, it must meet the same requirements as security between the > ETR and map server. Where is the cryptographic security between a host and a DNS resolver? Dino From jmh@joelhalpern.com Tue Aug 11 13:54:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A2B3A6EA5 for ; Tue, 11 Aug 2009 13:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN4rzDZt1BSp for ; Tue, 11 Aug 2009 13:54:58 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id DA7BC3A6B92 for ; Tue, 11 Aug 2009 13:54:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 870EEA3860 for ; Tue, 11 Aug 2009 13:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6A3664303A1 for ; Tue, 11 Aug 2009 13:53:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D54944303A2 for ; Tue, 11 Aug 2009 13:53:30 -0700 (PDT) Message-ID: <4A81DA49.6040803@joelhalpern.com> Date: Tue, 11 Aug 2009 16:53:29 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 20:54:59 -0000 Actually, Dino's last note (which I suspect he meant satirically) does suggest a different path. If we can use an SIDR-like approach to secure the origin information, this would seem to lead us to a simpler solution to use. If there are appropriate ROAs, and if the leaf ROAs point to the right thing, then with a slight variation we ought to be able to end up with a signable piece of information provided by the ETR into the system. (If someone can masquerade / intercept / pretend to be the MS and prevent the information from making its way into the system, they can probably do so even if there is more security in place.) Corrspondingly, the ITR does not need to know if it really reached the right MS, as long as it gets validly signed answers. Yes, there are a LOT more details needed. But that path avoids our needing to authenticate yet more pieces. And that path is needed anyway to get a meaningful security level on the system. Yours, Joel Dino Farinacci wrote: >> If others disagree, I'm happy to hold this issue open until we've >> actually done security analysis of the ITR map resolver security. I'm >> not comfortable closing this issue before that analysis. > > I disagree of course. If we build all this machinery, what you might be > suggesting, into these protocols, they will never get deployed. > > The LISP authors have stated that man-in-the-middle attacks on > infrastructure components are unlikely to occur so we believe they are > not problems. We made a judgement call so we can actually build a usable > architecture that can be deployed quickly and soon. > >> If cryptographic security is provided between the ITR and map >> resolver, it must meet the same requirements as security between the >> ETR and map server. > > Where is the cryptographic security between a host and a DNS resolver? > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mrw@sandstorm.net Tue Aug 11 14:07:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8563A68C2 for ; Tue, 11 Aug 2009 14:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Pgc+3SnnIHb for ; Tue, 11 Aug 2009 14:07:02 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4E44A3A6F6E for ; Tue, 11 Aug 2009 14:07:02 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BL5f61023688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 17:05:42 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <5B3216B4-1139-4665-889E-D83D764B3D31@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 17:05:41 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:07:03 -0000 On Aug 11, 2009, at 4:32 PM, Dino Farinacci wrote: > > I disagree of course. If we build all this machinery, what you might > be suggesting, into these protocols, they will never get deployed. I don't have enough knowledge of the alternatives to know if TLS is the best choice for securing LISP, but the IETF requires strong security with algorithm agility and automatic keying as a "must implement" in all IETF protocols. So, I do know that IPsec AH with manual shared keys won't cut it... > > The LISP authors have stated that man-in-the-middle attacks on > infrastructure components are unlikely to occur so we believe they > are not problems. We made a judgement call so we can actually build > a usable architecture that can be deployed quickly and soon. I'm sorry but "the LISP authors have stated" is not enough of an explanation for me to understand why man-in-the-middle attacks on infrastructure components are unlikely... Is there some compelling data or a sound argument to support this assertion? >> If cryptographic security is provided between the ITR and map >> resolver, it must meet the same requirements as security between the >> ETR and map server. > > Where is the cryptographic security between a host and a DNS resolver? The DNS has been identified as a major security concern for the Internet, and a massive effort is underway to deploy DNSSec to secure the DNS. I don't think we want to use the DNS as a model for the level of security required for a newly-defined RLOC-to-EID mapping system. Personally, I believe that including real security in the LISP specification, at a level that would allow standardization in the IETF, is important. We might be able to get away with something less on the basis that this is an "experimental protocol", but I'm afraid that would significantly lower the value of the experimental results, especially in the areas of performance and scalability. Margaret From mrw@sandstorm.net Tue Aug 11 14:09:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619DC3A6B72 for ; Tue, 11 Aug 2009 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3dzEqGntTMD for ; Tue, 11 Aug 2009 14:09:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CE95C3A6F6E for ; Tue, 11 Aug 2009 14:09:40 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BL7eHV023790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 17:07:40 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <40A5A913-C18A-464D-B6CA-A88AD128B19A@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 17:07:40 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:09:46 -0000 On Aug 11, 2009, at 4:37 PM, Dino Farinacci wrote: >> I think the right way to secure ETR->MS is to use TLS over a TCP >> connection. I've heard the arguments about why IPsec and TLS are >> inappropriate for BGP and I agree to a very large extent with these >> arguments. > > And what are the reasons you think TLS over TCP is inappropriate for > BGP? > > Don't forget the map-server must support up to 1000s of registered > sites. We chose a soft state solution so it can scale. How are you planning to pre-share keys between 1000s of registered sites? And, when keys need to be updated, how are you planning to send new keys to all of them? Margaret From jnc@mercury.lcs.mit.edu Tue Aug 11 14:17:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9D628C11C for ; Tue, 11 Aug 2009 14:17:06 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw0tKloJy++i for ; Tue, 11 Aug 2009 14:17:05 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9AA753A68C2 for ; Tue, 11 Aug 2009 14:17:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E769A6BE591; Tue, 11 Aug 2009 16:43:45 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811204345.E769A6BE591@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 16:43:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:17:06 -0000 > From: Margaret Wasserman > changing the text that indicates that LISP ITRs "MUST" send zero UDP > checksums to a "MAY". What's wrong with "SHOULD"? > Not checking non-zero UDP checksums on inbound traffic (at the ETR in > LISP) violates RFC 1122 (for IPv4) RFC 1122 is for _hosts_ (i.e. end-nodes), not for forwarding nodes, so you/we can ignore RFC-1122. > changing the text that indicates that LISP ETRs "MUST" ignore incoming > UDP checksums to a "MAY". "SHOULD". > Research .. and prior experience .. have indicated that it is (at least > sometimes) a very bad idea to disable and/or bypass UDP or IP checksums. Sure - for end-end traffic. This is encapsulated traffic, very different ball game. You can't recycle end-end usage analysis to this case. Noel From dino@cisco.com Tue Aug 11 14:21:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6716E28C11C for ; Tue, 11 Aug 2009 14:21:29 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY-btVj9SPFO for ; Tue, 11 Aug 2009 14:21:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 845BA3A68F2 for ; Tue, 11 Aug 2009 14:21:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANh9gUqrR7PE/2dsb2JhbAC7R4grkE8FhBk X-IronPort-AV: E=Sophos;i="4.43,362,1246838400"; d="scan'208";a="194626015" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2009 21:20:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7BLKF1k001855; Tue, 11 Aug 2009 14:20:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BLKFre027994; Tue, 11 Aug 2009 21:20:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 14:20:15 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 14:20:15 -0700 Message-Id: <71883097-A978-4FBC-AA36-C0E84EFFD752@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <40A5A913-C18A-464D-B6CA-A88AD128B19A@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 14:20:15 -0700 References: <40A5A913-C18A-464D-B6CA-A88AD128B19A@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Aug 2009 21:20:15.0102 (UTC) FILETIME=[84BA21E0:01CA1AC9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=961; t=1250025615; x=1250889615; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20management=20and=20security=2 0mechanism |Sender:=20; bh=Eqy/IGSUV2vk7cySzdCJ5g4GtvvIC7W/pf1yQqn8A+M=; b=ryhT1IqAX/LbsXK0TOBMBoio9QMlEJhnsxeu5OwIDzAkGjfifwH7inhA7A 9j9BpKxCNBb2j3I1+q9CA/UE2g8uDheCmx/homTOK0alTNml0pQ7TddcuWVD PTxD1Rqz4J; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:21:29 -0000 > On Aug 11, 2009, at 4:37 PM, Dino Farinacci wrote: > >>> I think the right way to secure ETR->MS is to use TLS over a TCP >>> connection. I've heard the arguments about why IPsec and TLS are >>> inappropriate for BGP and I agree to a very large extent with these >>> arguments. >> >> And what are the reasons you think TLS over TCP is inappropriate >> for BGP? >> >> Don't forget the map-server must support up to 1000s of registered >> sites. We chose a soft state solution so it can scale. > > How are you planning to pre-share keys between 1000s of registered > sites? And, when keys need to be updated, how are you planning to > send new keys to all of them? You configure them on each side. You do it at the same time on the map- server when you configure an EID-prefix and locator-set for the site. On the ETR side, you configure the key when you configure the address of the map-server. Dino > > Margaret > From mrw@sandstorm.net Tue Aug 11 14:23:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8DC3A67A8 for ; Tue, 11 Aug 2009 14:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdL8EPExMgR6 for ; Tue, 11 Aug 2009 14:23:08 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 670583A6DCB for ; Tue, 11 Aug 2009 14:23:08 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7BLLJD6024396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 17:21:20 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <378CA00B-F135-42B8-877D-E755B2A2AC81@sandstorm.net> From: Margaret Wasserman To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090811204345.E769A6BE591@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 17:21:19 -0400 References: <20090811204345.E769A6BE591@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:23:09 -0000 On Aug 11, 2009, at 4:43 PM, Noel Chiappa wrote: > >> Not checking non-zero UDP checksums on inbound traffic (at the ETR in >> LISP) violates RFC 1122 (for IPv4) > > RFC 1122 is for _hosts_ (i.e. end-nodes), not for forwarding nodes, > so you/we > can ignore RFC-1122. Nice try. :-) But, if you claim that LISP xTRs don't have to comply with RFC 1122 because they are routers, then they do need to comply with RFC 1812 (Requirements for IP Version 4 Routers), which says: "6.1 USER DATAGRAM PROTOCOL - UDP The User Datagram Protocol (UDP) is specified in [TRANS:1]. A router that implements UDP MUST be compliant, and SHOULD be unconditionally compliant, with the requirements of [INTRO:2], except that: o This specification does not specify the interfaces between the various protocol layers. Thus, a router's interfaces need not comply with [INTRO:2], except where compliance is required for proper functioning of Application Layer protocols supported by the router. o Contrary to [INTRO:2], an application SHOULD NOT disable generation of UDP checksums. DISCUSSION Although a particular application protocol may require that UDP datagrams it receives must contain a UDP checksum, there is no general requirement that received UDP datagrams contain UDP checksums. Of course, if a UDP checksum is present in a received datagram, the checksum must be verified and the datagram discarded if the checksum is incorrect." I would not object to replacing "RFC 1122" with "RFC 1812" in my issue description, though. >> >> Research .. and prior experience .. have indicated that it is (at >> least >> sometimes) a very bad idea to disable and/or bypass UDP or IP >> checksums. > > Sure - for end-end traffic. This is encapsulated traffic, very > different ball > game. You can't recycle end-end usage analysis to this case. Given the "SHOULD NOT" in RFC 1812 and the other evidence presented, I think that the burden is on us to prove that turning off UDP checksums in LISP will not cause a problem for the LISP protocol itself, or for other hosts and applications that need to co-exist with it. Margaret From hartmans@mit.edu Tue Aug 11 14:28:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B557B3A6B5D for ; Tue, 11 Aug 2009 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euvpc+ahV98w for ; Tue, 11 Aug 2009 14:28:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 1A1223A67A8 for ; Tue, 11 Aug 2009 14:28:17 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 94C9651C7; Tue, 11 Aug 2009 17:26:49 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090811204345.E769A6BE591@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 11 Aug 2009 17:26:49 -0400 In-Reply-To: <20090811204345.E769A6BE591@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue\, 11 Aug 2009 16\:43\:45 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:28:17 -0000 Can we please wait until the authors or secretary opens these issues and assigns numbers before discussing in this thread? From jnc@mercury.lcs.mit.edu Tue Aug 11 14:31:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C41D3A68C2 for ; Tue, 11 Aug 2009 14:31:37 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiLd1eURD6nu for ; Tue, 11 Aug 2009 14:31:36 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5E1F13A6969 for ; Tue, 11 Aug 2009 14:31:36 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4F09B6BE5CC; Tue, 11 Aug 2009 17:06:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811210600.4F09B6BE5CC@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 17:06:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:31:37 -0000 > From: Dino Farinacci > If we build all this machinery, what you might be suggesting, into > these protocols, they will never get deployed. > ... > We made a judgement call so we can actually build a usable architecture > that can be deployed quickly and soon. I basically agree with you, with one tiny potential difference: I'd like to see the right hooks (i.e. packet fields) added now, for things we are going to need eventually, even if we don't actually use them now (e.g. insert as AuthType '1 = No Authentication'). I know that may sound kind of silly, but it avoids having to i) rev the protocol, ii) design interoperability mechanisms between different protocol revs so that deployed base can talk to new stuff, etc, on down the road. Noel From hartmans@mit.edu Tue Aug 11 14:32:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4F73A6F27 for ; Tue, 11 Aug 2009 14:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyKBeREDEBIW for ; Tue, 11 Aug 2009 14:32:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id F326B3A6F37 for ; Tue, 11 Aug 2009 14:32:14 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F2B5351C6; Tue, 11 Aug 2009 16:56:17 -0400 (EDT) To: Margaret Wasserman References: <4A97E2C4-056C-4CC9-8B1D-AB7FEED268DF@sandstorm.net> From: Sam Hartman Date: Tue, 11 Aug 2009 16:56:17 -0400 In-Reply-To: <4A97E2C4-056C-4CC9-8B1D-AB7FEED268DF@sandstorm.net> (Margaret Wasserman's message of "Tue\, 11 Aug 2009 16\:26\:37 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:32:15 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Hi Sam, Margaret> On Aug 11, 2009, at 4:13 PM, Sam Hartman wrote: >> > * RFC 2401 and 2402 have been obsoleted by a new and somewhat >> different IPsec model. Margaret> Where is the new model documented? RFC 4301. From jnc@mercury.lcs.mit.edu Tue Aug 11 14:48:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F08B3A6EA0 for ; Tue, 11 Aug 2009 14:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzr+IvVp+zSZ for ; Tue, 11 Aug 2009 14:48:44 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8A54F3A6F37 for ; Tue, 11 Aug 2009 14:48:44 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C318B6BE59B; Tue, 11 Aug 2009 16:55:47 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811205547.C318B6BE59B@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 16:55:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 21:48:45 -0000 > From: Sam Hartman > The only protection of the map reply is that it needs to have the same > nonce as the map request. Long term, that is unlikely to be good > enough. Sure, but in the short term, it's no worse than most DNS lookups are today (and maybe better, since it does require on-path visibility into the packets). Acceptable for an experiment; something we should fix in the long run. Someone had a proposal to add some authentication stuff in the Request/Reply packets, which I basically agree with - the Request/Reply packet format should include the right fields to authenticate mapping entries, even if they are blank during the experimental phase. (Note: I am not talking about node-node security, on a hop-by-hop basis - I am talking about authentication of _mapping entries_, which stays with them from the time the mapping is created, until it gets to the ultimate consumer. Then of course there's a whole key-distribution thing to deal with, but that's a separate nightmare.) > I understand that the alt does not currently provide cryptographic > security. Right, and the ALT itself might be replaced in toto at some point. > If cryptographic security is provided between the ITR and map resolver, > it must meet the same requirements as security between the ETR and map > server. I'm uncomfortable having link-based security (i.e. "between the ITR and map resolver", or "between the ETR and map server"). I'd rather secure the mappings 'at birth', and distribute the authentication along with the mapping. That way, nobody has to trust any entities between the i) ultimate creator of the mapping, and ii) the ultimate consumer. Also, a break-in to any intermediate node cannot compromise the mapping either. (Yeah, you can DoS, but that's a given for any break-in.) Noel From sthaug@nethelp.no Tue Aug 11 01:18:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94AA3A6FB0 for ; Tue, 11 Aug 2009 01:18:00 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kExJPOerPURi for ; Tue, 11 Aug 2009 01:18:00 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by core3.amsl.com (Postfix) with SMTP id ED7CF3A6F9C for ; Tue, 11 Aug 2009 01:17:59 -0700 (PDT) Received: (qmail 63945 invoked from network); 11 Aug 2009 08:11:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Aug 2009 08:11:23 -0000 Date: Tue, 11 Aug 2009 10:11:23 +0200 (CEST) Message-Id: <20090811.101123.74696609.sthaug@nethelp.no> To: mrw@sandstorm.net From: sthaug@nethelp.no In-Reply-To: <99D56D74-9C01-4C95-AA37-461CE088612F@sandstorm.net> References: <75cb24520908071159j225443eam5db10ec1924caa9f@mail.gmail.com> <99C129FC-5C9A-4D7C-B75A-7CB543608C6D@americafree.tv> <99D56D74-9C01-4C95-AA37-461CE088612F@sandstorm.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Aug 2009 15:00:00 -0700 Cc: ipv6@ietf.org, lisp@ietf.org Subject: Re: [lisp] Flow label redux X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 08:18:00 -0000 > >> The dataset analyzed is not relevant to today's networking > >> connectivity or technologies. Looking very quickly at a small set of > >> data I have access to (servers serving web content to the internet > >> users): > >> > >> 32,945,810,591 packets received, 0 dropped due to bad checksum (ip > >> header checksum) > >> > >> 1,004,728,008 datagrams received, 0 bad checksum, 15886 with no > >> checksum (udp datagram stats) Checking six of our name servers here (some pure recursive, some pure authoritative): - 11,125,766,153 IP packets received, with 0 bad header checksums - 9,311,954,730 UDP datagrams received, with 1,300,228 bad checksums Thus IP header checksum really looks like it is very close to zero, probably because any IP packets with bad header checksums would be dropped by the closest router. However, the UDP bad checksum rate is very definitely not zero. I get a rate of 1.39e-4 for my dataset. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fred@cisco.com Tue Aug 11 10:14:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD33A3A69A2; Tue, 11 Aug 2009 10:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.944 X-Spam-Level: X-Spam-Status: No, score=-105.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJOvJpay0udq; Tue, 11 Aug 2009 10:14:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6060B3A6C1C; Tue, 11 Aug 2009 10:14:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,361,1246838400"; d="scan'208";a="226465517" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2009 17:13:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7BHDWus003385; Tue, 11 Aug 2009 10:13:32 -0700 Received: from [192.168.1.100] (sjc-vpn3-305.cisco.com [10.21.65.49]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7BHDWFf000200; Tue, 11 Aug 2009 17:13:32 GMT Message-Id: From: Fred Baker To: Dino Farinacci In-Reply-To: <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 10:13:31 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1308; t=1250010812; x=1250874812; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=3pMSCms93/2zYH9sNj83kF8/LnsGtzWwZ9FOyq6t7Us=; b=PFgdJzdty4L2BhFZ6QBq0GeQZbRrEC+r7Vtvc4oSayKcw/tJ1FjBAFx0iB ICYLEeihSHcv18CIN5xNIGQ13UbnagVnSEpHY+hAbmtrd7de4FCDBdDPECIj jp3b6XN2Dh; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Tue, 11 Aug 2009 15:00:00 -0700 Cc: lisp@ietf.org, ipv6@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 17:14:58 -0000 > "UDP Checksum: this field MUST be transmitted as 0 and ignored on > receipt by the ETR. Note, even when the UDP checksum is transmitted > as 0 an intervening NAT device can recalculate the checksum and > rewrite the UDP checksum field to non-zero. For performance reasons, > the ETR MUST ignore the checksum and MUST not do a checksum > computation." I would expect a NAT that saw a zero value to not recalculate the checksum. I agree that the unilateral change to the UDP protocol built into RFC 2460 was a bad idea; if you want to change UDP, change UDP. That is probably water under the bridge now. I think that I would word this as: UDP Checksum: this field MAY be transmitted as zero, and the receiver MAY ignore the checksum on receipt. As to the performance issues, that is an implementation question. You can do a full packet checksum at 100 GBPS if you want to, it just has a cost implication (very different hardware than the usual store-and- forward design). The datagram will likely have to be handled in a flow- through manner and the checksum read from a register upon completion. The argument in favor of this is, I think, that the interior packet has checksums on it, so this one is not called for, by the end-to-end principle. From olivier.bonaventure@uclouvain.be Tue Aug 11 15:19:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7753A6917 for ; Tue, 11 Aug 2009 15:19:57 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN8-+bW8TT6Q for ; Tue, 11 Aug 2009 15:19:56 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id B58FB3A682F for ; Tue, 11 Aug 2009 15:19:56 -0700 (PDT) Received: from mbpobo.local (ip-80-236-248-173.dsl.scarlet.be [80.236.248.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C691BF236B; Tue, 11 Aug 2009 23:44:06 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be C691BF236B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1250027047; bh=iSxBZ2HNq5kOAMLzemIMTWdb1jzfYY8mzoFH+dTf+Dc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FXtP9UuDUAZmPfNJCIsAZrqEzRQ15lKQHjMmSmbU11fD4k0lh1qoiOYUXjFh6pl1A E8+ob5LOXWjFCdwZMkryOvj3Qor116itiZts3taEFYq6AVDztLUZIc8lhlEZwVYGfp F/oljaNf8Jy0xtM9nARjiQ1MXKKU6HN3s3p6vftA= Message-ID: <4A81E618.9080801@uclouvain.be> Date: Tue, 11 Aug 2009 23:43:52 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: C691BF236B.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 11 Aug 2009 22:19:57 -0000 Sam, > > Currently draft-ietf-lisp-ms describes the use of RFC 2402 H with MD5 > preshared keys as the mandatory to implement mechanism between an ETR > and a map server . I agree with you that this is unlikely to be the best standardised solution to authenticate the exchange between an ETR and a map server. However, as for issue #3, I think that we should first define whether we consider that LISP should work correctly even if there is - an on-path attack - only off-path attacks Once we have decided the capabilities of our target attacker, then we can discuss the mechanisms that need to be used to counter such attackers. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Tue Aug 11 15:21:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EA23A6A78 for ; Tue, 11 Aug 2009 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.582 X-Spam-Level: X-Spam-Status: No, score=-7.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDSZdr0L08+K for ; Tue, 11 Aug 2009 15:21:42 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4A1803A682F for ; Tue, 11 Aug 2009 15:21:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ACC066BE597; Tue, 11 Aug 2009 17:51:11 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 17:51:11 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Aug 2009 22:21:43 -0000 > From: Margaret Wasserman > if you claim that LISP xTRs don't have to comply with RFC 1122 because > they are routers, then they do need to comply with RFC 1812 > (Requirements for IP Version 4 Routers) Well, if we're going to descend into red-tape legalese, I'll simply argue that they aren't routers _either_... :-) But to be serious for a moment: > "if a UDP checksum is present in a received datagram, the checksum must > be verified and the datagram discarded if the checksum is incorrect." The problem is that given the large number of NAT boxes _already deployed in the network_ which don't correctly handle UDP checksums, this is all nice verbiage, but it's totally overtaken by the tidal wave of reality. Following the letter of that rule would result in discarding datagrams which are perfectly fine, but have been damaged in transit by incorrectly operating, but unfortunately widely deployed, devices. More generally: I forget which US Supreme Court justice that said 'the U.S. Constitution is not a suicide pact'. When slavish adherence to the letter of the written thing produces results that common sense says are nonsensical, you have to be willing to step back and apply a little common sense. Something similar applies to specification documents. Rigid adherence to old protocol specifications, specifications which i) don't really apply to a new application which is somewhat sui generis, and ii) have been effectively obsoleted by the widespread deployment of devices which violate the operation of the protocol, just doesn't make sense. In cases like that, you just have to go back to using sound engineering judgment. Look, these prior RFCs weren't handed down on stone tablets from super-beings who are an order of magnitude smarter than us. (And some of the people who wrote them are still here... :-) I see no reason to treat them with awed deference. They were put together by people with a practical engineering take on things. Good engineering ought to trump papework rules. If the IETF process isn't able to do that, it has developed a real problem. Noel From olivier.bonaventure@uclouvain.be Tue Aug 11 16:05:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A4C3A6EB3 for ; Tue, 11 Aug 2009 16:05:14 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeDn5BVSeSux for ; Tue, 11 Aug 2009 16:05:13 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 3B7993A6B5A for ; Tue, 11 Aug 2009 16:05:13 -0700 (PDT) Received: from mbpobo.local (ip-80-236-248-173.dsl.scarlet.be [80.236.248.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 529511C5695; Tue, 11 Aug 2009 23:39:45 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp3.sgsi.ucl.ac.be 529511C5695 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1250026785; bh=F3OAMIHM3rLnYwxUY3H8xnCaGJ1Gb/jiA8davb4WEGw=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zEKKm0JbDvhFcQatk4RXa2ThV3qR+3zyyI7qLoM+qzMq/tgMtKnmBv8QnSWi8E4Ex uHBQxR1Olq6/UiVxo4fUVkS792EPSNejPabp1wuuO/QRr5/Zhb9dLyC6LcnUcUYGZk QB8gfXuhofww7Qpu6W+jAnlyFoxKGK2e2fKdmEjg= Message-ID: <4A81E520.808@uclouvain.be> Date: Tue, 11 Aug 2009 23:39:44 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 529511C5695.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 11 Aug 2009 23:05:14 -0000 Sam, > > Currently, the interface between the ITR and map resolver has two > security concerns. > > * There is no integrity protection of the exchange between the ITR and map resolver > > * An ITR accepts a reply from any ETR, which makes it hard to add security. > ... > > If others disagree, I'm happy to hold this issue open until we've > actually done security analysis of the ITR map resolver security. I'm > not comfortable closing this issue before that analysis. I think that this kind of discussion cannot start before we agree on the type of security attacks that LISP must avoid. For example, I'm not convinced that we need to counter on-path attacks with LISP. However, LISP should probably not be vulnerable to off-path attacks, including those with spooffed packets. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Tue Aug 11 17:35:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36DB3A67E4 for ; Tue, 11 Aug 2009 17:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps18dumwZmkN for ; Tue, 11 Aug 2009 17:35:37 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 224873A66B4 for ; Tue, 11 Aug 2009 17:35:36 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6D2A06BE5CC; Tue, 11 Aug 2009 20:08:15 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> Date: Tue, 11 Aug 2009 20:08:15 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: fred@cisco.com, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 00:35:38 -0000 > From: Fred Baker > I think that I would word this as: > UDP Checksum: this field MAY be transmitted as zero, and the receiver > MAY ignore the checksum on receipt. Now that I think about it, while this may pass muster in terms of meeting standards, from an engineering standpoint, this is a bad idea. In giving people the option to _not_ ignore the checksum, while also allowing people to not _set_ it, it creates situations which go against one of the key architectural principles of the Internet, Postel's Principle: 'Be liberal in what you receive'. Consider a case where one has an ITR which has availed itself of the opportunity to not set UDP checksums on user-data traffic (perhaps it has no choice, being run on router hardware which doesn't even give the forwarding engine access to the entire packet), trying to send packets to an ETR which has decided not to accept packets which don't have a checksum. Needless to say, the ETR won't accept any packets from that ITR. Even if we say 'OK, so the ETR can only check checksums on packets that have them', we still have the issue that there are lots of deployed boxes that bash checksums without checking to make sure they are zero, before so doing. So if there's one of those on the path, we're back to the same situation: a 'no-checksum' ITR can't talk to a 'wants-checksum' ETR. So if the spec does eventually say something like the above (i.e. allow both not setting checksums on transmission, and checking them on reception), it needs to have something like this in it: "Note that an ETR which checks checksums may not be able to accept packets from an ITR which is not setting them. Since there are expected to be many such ITRs in service, such ETRs may thus have limited utility." I mean, I think we are obligated to warn people who 'implement to the spec' up front, and very plainly, that certain implementation choices will result in devices with limited usability. Noel From hartmans@mit.edu Tue Aug 11 20:18:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC16E3A69ED for ; Tue, 11 Aug 2009 20:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiejog2fhCI0 for ; Tue, 11 Aug 2009 20:18:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 110E23A6982 for ; Tue, 11 Aug 2009 20:18:41 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A4EC641DA; Tue, 11 Aug 2009 23:17:36 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 11 Aug 2009 23:17:36 -0400 In-Reply-To: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue\, 11 Aug 2009 20\:08\:15 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, fred@cisco.com Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 03:18:43 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Fred Baker I think that I would word >> this as: UDP Checksum: this field MAY be transmitted as zero, >> and the receiver MAY ignore the checksum on receipt. Noel> Now that I think about it, while this may pass muster in Noel> terms of meeting standards, from an engineering standpoint, Noel> this is a bad idea. It doesn't pass muster from a standards point of view, exactly because of the reason you cite below. Noel> In giving people the option to _not_ Noel> ignore the checksum, while also allowing people to not _set_ Noel> it, it creates situations which go against one of the key Noel> architectural principles of the Internet, Postel's Noel> Principle: 'Be liberal in what you receive'. Noel> Consider a case where one has an ITR which has availed Noel> itself of the opportunity to not set UDP checksums on Noel> user-data traffic (perhaps it has no choice, being run on Noel> router hardware which doesn't even give the forwarding Noel> engine access to the entire packet), trying to send packets Noel> to an ETR which has decided not to accept packets which Noel> don't have a checksum. Needless to say, the ETR won't accept Noel> any packets from that ITR. Thanks for pointing this out. You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums. From hartmans@mit.edu Tue Aug 11 20:22:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6703A699C for ; Tue, 11 Aug 2009 20:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XclVqCmMhSs for ; Tue, 11 Aug 2009 20:22:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4EB5A3A685C for ; Tue, 11 Aug 2009 20:22:20 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA600641DA; Tue, 11 Aug 2009 23:20:22 -0400 (EDT) To: Olivier.Bonaventure@uclouvain.be References: <4A81E618.9080801@uclouvain.be> From: Sam Hartman Date: Tue, 11 Aug 2009 23:20:22 -0400 In-Reply-To: <4A81E618.9080801@uclouvain.be> (Olivier Bonaventure's message of "Tue\, 11 Aug 2009 23\:43\:52 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 03:22:21 -0000 >>>>> "Olivier" == Olivier Bonaventure writes: Olivier> Sam, >> >> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H >> with MD5 preshared keys as the mandatory to implement mechanism >> between an ETR and a map server . Olivier> I agree with you that this is unlikely to be the best Olivier> standardised solution to authenticate the exchange Olivier> between an ETR and a map server. However, as for issue Olivier> #3, I think that we should first define whether we Olivier> consider that LISP should work correctly even if there is Olivier> - an on-path attack - only off-path attacks Olivier> Once we have decided the capabilities of our target Olivier> attacker, then we can discuss the mechanisms that need to Olivier> be used to counter such attackers. I can see your point for #3. However for #2, I disagree, because what we have is very clearly not good enough to get published in the IETF at all. From hartmans@mit.edu Wed Aug 12 02:46:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367A03A6977 for ; Wed, 12 Aug 2009 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-6lvivyXpgu for ; Wed, 12 Aug 2009 02:46:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 68F6E3A635F for ; Wed, 12 Aug 2009 02:46:19 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2209F51C6; Wed, 12 Aug 2009 05:44:04 -0400 (EDT) To: "Templin\, Fred L" References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 12 Aug 2009 05:44:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: [lisp] [#4] Re: LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 09:46:20 -0000 >>>>> "Templin," == Templin, Fred L writes: Templin,> In addition to errors that may occur along the path from Templin,> the ITE to the ETE *before* decapsulation and errors Templin,> that may occur along the path from the ETE to the final Templin,> destination *after* decapsulation, errors may also occur Templin,> *during* decapsulation. An example is what if the ETR Templin,> decapsulates the outer IP header, but the inner IP stack Templin,> is not configured? (Answer is that the ITR should Templin,> receive an error by which it can ascertain that this ETR Templin,> is having trouble, and should start using a different Templin,> ETR instead.) Templin,> This gives rise to a type of error message that is Templin,> neither fish nor fowl, i.e., it is neither an RLOC-based Templin,> nor an EID-based ICMP error - it is a *LISP* error Templin,> instead. One approach is to have the ETR send such a Templin,> LISP error back to the ITR with enough identifying Templin,> credentials such that the ITR can be reasonably sure the Templin,> message is authentic. The message should further not be Templin,> dropped by packet filters on the path from the ETR to Templin,> the ITR that filter "naked" ICMP messages. Fred, this is opened as issue #4. I've attached the following chair note to the issue: Fred opened this issue before the issue tracker was available. Discussion on the list suggested that Fred's original conception might not have WG consensus, but the general problem of when LISP should send errors and how this should be done definitely is an open issue. From hartmans@mit.edu Wed Aug 12 03:32:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9083A697D for ; Wed, 12 Aug 2009 03:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsZvaYEyzRAe for ; Wed, 12 Aug 2009 03:32:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 5A1723A67F5 for ; Wed, 12 Aug 2009 03:32:07 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2385641DA; Wed, 12 Aug 2009 06:30:55 -0400 (EDT) To: Dino Farinacci References: From: Sam Hartman Date: Wed, 12 Aug 2009 06:30:55 -0400 In-Reply-To: (Dino Farinacci's message of "Tue\, 11 Aug 2009 13\:37\:38 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 10:32:08 -0000 >>>>> "Dino" == Dino Farinacci writes: >> I think the right way to secure ETR->MS is to use TLS over a >> TCP connection. I've heard the arguments about why IPsec and >> TLS are inappropriate for BGP and I agree to a very large >> extent with these arguments. Dino> And what are the reasons you think TLS over TCP is Dino> inappropriate for BGP? 1) in BGP, having a connection torn down has significant effects; TLS alone does not protect against connection resets 2) Architecturally on deployed routers implementing TLS would be tricky without exposing the control plane processor to DOS concerns. 3) It would be a significant implementation change to decouple the transport and session states for BGP The deployment model of a map server looks a lot more like the TLS deployment model we have highly optimized in hardware: the map server talks to a large number of clients (ETRs) each of which talks to one or a small number of map servers. Dino> Don't forget the map-server must support up to 1000s of Dino> registered sites. We chose a soft state solution so it can Yes. This is one of the main reasons I suggest TLS: it has proven scaling to this size and hardware acceleration is easily available. Honestly, I'm not sure you'd need it for the work loads you're talking about, although it might be desirable if you had thousands of ETRs all cold-starting against a map server with no state. I'm not going to say much more on TLS; I need to preserve my ability to judge consensus on this issue and don't want to get too involved in advocating a specific solution. Here are some other solutions that would almost certainly be able to meet your needs: * DTLS+UDP -- used by capwap If you dislike TCP, you can do this. It will be more complicated to specify than TLS over TCP, and I don't see what it buys you since I think both solutions scale to more than you care about. As mentioned, CAPWAP is the best example of this. * DTLS +extractor for a MAC in a packet Use the DTLS initial exchange to set up keys that you then use for some per-packet MAC. Significantly more complicated to specify than the above, although perhaps not as bad as IPsec (although perhaps worse). The benefit is that you don't need DTLS wrapping on each packet; the disadvantage is that it performs the same, is more complicated to analyze, and may be more difficult to code. I think that SRTP's use of DTLS is similar enough to this to count as a success story. * IPsec (IKEV2 + esp null) May interact poorly with other uses of IPsec on the same device. Fairly difficult to standardize; there are a lot of tricky bits to specify. May end up involving more state than TLS between the PAD entry, the SPD entry, and the SAD entry. I can't think of any success stories with this approach. OSPF V3 does this, but I think both the security community and the routing community were vaguely unhappy with the results. * Kerberos You could do this; it would work fine although it would be an unusual application of Kerberos. Kerberos doesn't typically have hardware acceleration available. For this application that's probably not a show stopper, although I suspect a lot of people on this list would feel more comfortable adopting a technology with hardware acceleration. This would actually involve very little state on the map server, although it would involve a Kerberos KDC somewhere. That's stateless (except for the configuration of the principal database) too, although seems like a lot of unneeded complexity for this application. It would be easy to specify. I include this only for completeness. From mrw@sandstorm.net Wed Aug 12 07:13:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F6A3A6886 for ; Wed, 12 Aug 2009 07:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6L8Oepw9iIq for ; Wed, 12 Aug 2009 07:13:47 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AEFBB3A683F for ; Wed, 12 Aug 2009 07:13:46 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CEC2g6068951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 10:12:02 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 10:12:01 -0400 References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 14:13:48 -0000 On Aug 11, 2009, at 5:51 PM, Noel Chiappa wrote: >> "if a UDP checksum is present in a received datagram, the checksum >> must >> be verified and the datagram discarded if the checksum is incorrect." > > The problem is that given the large number of NAT boxes _already > deployed in > the network_ which don't correctly handle UDP checksums, this is all > nice > verbiage, but it's totally overtaken by the tidal wave of reality. > > Following the letter of that rule would result in discarding > datagrams which > are perfectly fine, but have been damaged in transit by incorrectly > operating, > but unfortunately widely deployed, devices. I understand that some of us want to implement LISP on devices that are incapable of calculating UDP checksums at an acceptable rate of performance. I also understand that there are widely deployed low-end NAT boxes for which the current software is broken, so that it corrupts all zero UDP checksums. The solution that you propose is to forbid the ETR from calculating the received checksum. Unfortunately, that solution has costs: (1) It makes LISP less compatible with currently implemented, RFC- compliant TCP/IP stacks (which are far more widely deployed than the devices mentioned above). (2) It means that if we discover later that there are problems caused by the use of UDP zero checksums (either for LISP or for other hosts and applications with which we need to co-exist, either in IPv4 or IPv6), we _can't_ turn on UDP checksums to solve the problem. Personally, I would rather have language in the specification that indicates that all ITRs and ETRs must be capable of supporting UDP checksums. However, for performance reasons, ITRs MAY (or even SHOULD) send zero checksums. I am not at all comfortable with language that says that LISP ETRs should ignore non-zero checksums on receipt, because of the costs listed above. I _do_ understand that this means that LISP won't work (at all) when used through the aforementioned buggy NAT boxes. But, it isn't clear to me that LISP can work through those NAT boxes, anyway. Nor is it clear to me why we would care to place this requirement on LISP (that it work through NAT boxes), any more than we care whether it works through IPv4/IPv6 translators. There are a number of reasons why I don't believe that placing an xTR behind a typical IPv4 NAT box will work: (1) Mapping look-up replies do not always come from the same host to which they were sent. Those replies will be dropped by the NAT box, since there is no state to indicate where to send them. (2) NAT boxes do not limit themselves to corrupting the UDP checksum. They will also modify the source RLOC (the source IP address), the IP header checksum, and the source UDP port in the outer header. This means that the EID to RLOC mapping for all nodes inside the site will need to use the external address of the NAT as the RLOC. However, LISP doesn't specify a mechanism for determining what that external address is, or noticing when it changes. (3) The IP addresses used behind these NAT boxes are typically private addresses (from net 10 or another private prefix). If these addresses are used as EIDs (by the end nodes that don't even know that their traffic will be LISP encapsulated), they will not be translated by the NAT box (since there is no LISP ALG). They will be meaningless (or worse) when the traffic is decapsulated on the other end. There are even bigger problems if _both_ ends are behind a NAT, as LISP doesn't contain any mechanism to set-up the state needed for two nodes (an ITR and an ETR) behind NATs to set-up communication with each other. I also haven't considered what would happen if a mapping server was behind a NAT box. Now, I realize that a sophisticated person with administrative access to the NAT box could do things like: - set up a static port mapping for traffic to the LISP port(s) to reach the LISP xTR. - configure the NAT box (or another DHCP server) to provide allocated EIDs internally, instead of private addresses. Or even configure the internal nodes manually. - determine the address that is used outside the NAT, and register that mapping in the LISP mapping system (although it unclear to me how changes will be detected). But, couldn't a person who has that level of access and expertise just upgrade his buggy NAT software? Or, better yet, _replace_ his NAT with something that sucks less? People who are behind a NAT box that they do not control won't be able to configure the NAT to allow LISP to work through it, anyway. So, exactly what problem are we trying to solve by mandating that ETRs must not check non-zero checksums? Margaret From mrw@sandstorm.net Wed Aug 12 07:27:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426E73A6AE0 for ; Wed, 12 Aug 2009 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKvjna5BoHjD for ; Wed, 12 Aug 2009 07:27:10 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 51EF93A6AC0 for ; Wed, 12 Aug 2009 07:27:10 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CEPXNi069948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 10:25:33 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <636567C2-4111-4078-9A6C-B2EC15322665@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 10:25:32 -0400 References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, fred@cisco.com Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 14:27:11 -0000 Hi Noel, On Aug 11, 2009, at 8:08 PM, Noel Chiappa wrote: > From: Fred Baker >> >> I think that I would word this as: >> UDP Checksum: this field MAY be transmitted as zero, and the receiver >> MAY ignore the checksum on receipt. > Now that I think about it, while this may pass muster in terms of > meeting > standards, from an engineering standpoint, this is a bad idea. In > giving > people the option to _not_ ignore the checksum, while also allowing > people to > not _set_ it, it creates situations which go against one of the key > architectural principles of the Internet, Postel's Principle: > 'Be liberal in what you receive'. By "MAY ignore checksums", I don't think Fred meant to indicate that such an ETR would throw out packets with zero checksums. The process of checking a zero UDP checksum is to notice that it is zero and stop. What it does mean is that ITRs may send non-zero checksums, and ETRs may check those non-zero checksums. BTW, the above wording is _not_ RFC compliant. The "MAY be transmitted as zero" is compliant for IPv4, but not for IPv6 (RFC 2460). And, the "MAY ignore [non-zero] checksums on receipt" is not compliant with RFCs 768, 1122, 1812 and/or 2460. Like you, though, my main concern is not compliance with those old RFCs. If we determine that the right choice, technically/ architecturally, is to do something that doesn't comply with those RFCs, we just need to write another RFC that indicates when and why an exception is acceptable, and convince the IETF to publish it. If our technical/architectural reasons is correct, that should be possible. Before we can do that, though, I think we need to reach agreement amongst ourselves as to what is the best technical/architectural choice. Margaret From dino@cisco.com Wed Aug 12 08:24:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01433A6A6C for ; Wed, 12 Aug 2009 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoiaQ7ZaTI+8 for ; Wed, 12 Aug 2009 08:24:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 110FE3A69EE for ; Wed, 12 Aug 2009 08:24:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKt7gkqrR7PE/2dsb2JhbAC6IIgrkRQFhBmKFw X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="183003971" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2009 15:22:59 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7CFMxnm007716; Wed, 12 Aug 2009 08:22:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7CFMxxa008620; Wed, 12 Aug 2009 15:22:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 08:22:59 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 08:22:59 -0700 Message-Id: <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 08:22:59 -0700 References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 15:22:59.0209 (UTC) FILETIME=[C65A2F90:01CA1B60] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=630; t=1250090579; x=1250954579; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=Z/yPtO6eltK0zyZWuT6WI8irBHylW0zOncarROCU4eA=; b=HqgW/bjQJmJnkQbPeKx2Hpah/EqJkdVSkBUmMCoLwQuE5rw/qGMTN6rT80 FrugFUusrI9aodRx09DurhUrhP/gVB3e6sF6wE9xQLCoHm+at/ug6ZbzkhuM kvxyvyuU5r; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: fred@cisco.com, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 15:24:40 -0000 On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: > You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST > accept a 0 checksum and MAY ignore the checksum completely. And of Anyone object to me putting this text in the -04 spec now? Then, could we close this issue? Dino > course we'd need to confirm that can actually be implemented. In > particular, hardware that verifies UDP checksums on receive needs to > be checked to make sure it permits 0 checksums. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mrw@sandstorm.net Wed Aug 12 08:43:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0A13A6B56 for ; Wed, 12 Aug 2009 08:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On1vNobmNKS3 for ; Wed, 12 Aug 2009 08:43:02 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5A4C93A6838 for ; Wed, 12 Aug 2009 08:43:02 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CFfFmN073727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 11:41:15 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <75C38DEF-C419-448D-84B6-542429305792@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 11:38:18 -0400 References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, fred@cisco.com, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 15:43:03 -0000 On Aug 12, 2009, at 11:22 AM, Dino Farinacci wrote: > On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: > >> You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST >> accept a 0 checksum and MAY ignore the checksum completely. And of > > Anyone object to me putting this text in the -04 spec now? While this doesn't address all of my concerns about the UDP checksum handling, I consider this text to be much better than the current text, so go ahead and include it. You should include a normative reference to Marshall's IPv6 zero checksum draft after "ITRs MAY send a zero checksum", because you will need a normative reference to a standards track RFC that says this is an okay thing to do in IPv6. His draft can be found here: http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt You should also include a "[Ref Needed]" placeholder, or something similar, after "MAY ignore the checksum completely", because you will need a normative reference to a standards track RFC that indicates that this is an okay thing to do for both IPv4 and IPv6, as well. Margaret From dino@cisco.com Wed Aug 12 08:46:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C3B3A6826 for ; Wed, 12 Aug 2009 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvm+BvLuEnnL for ; Wed, 12 Aug 2009 08:46:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 735433A6803 for ; Wed, 12 Aug 2009 08:46:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJeAgkqrR7PE/2dsb2JhbAC6XogrkQ8FhBmBUQ X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="227000545" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 15:44:57 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7CFivNV032554; Wed, 12 Aug 2009 08:44:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7CFivFm014946; Wed, 12 Aug 2009 15:44:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 08:44:57 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 08:44:56 -0700 Message-Id: <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 08:44:54 -0700 References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 15:44:56.0929 (UTC) FILETIME=[D7C64D10:01CA1B63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=848; t=1250091897; x=1250955897; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Checksum-related=20issues=20fo r=20the=20tracker |Sender:=20; bh=LEiqdptN1bEff62Um7No5h2T5Si69kiVstQLNZNkRfQ=; b=NVP9Zcf0xG/pfyXWl3QW+Wk1bNf4DvRl2zx8vvrTmP48LYdq9EOcsQVBan 6EdpgzimvULLaEfK6RFEIQ/3PagLuuKnZX6caNcaTXvKLNLhWoGa0/gsypyQ C2eLz4nEcI; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 15:46:50 -0000 > I _do_ understand that this means that LISP won't work (at all) when > used through the aforementioned buggy NAT boxes. But, it isn't > clear to me that LISP can work through those NAT boxes, anyway. Nor > is it clear to me why we would care to place this requirement on > LISP (that it work through NAT boxes), any more than we care whether > it > works through IPv4/IPv6 translators. Let me make this crystal clear. (1) LISP does work through NATs today. We have an existence proof, many of the boxes on the LISP network are behind NATs. (2) LISP *is* compliant with RFCs regarding 0 UDP-checksuming when IPv4 is the outer header. What you state is an issue is only when the outer header is IPv6. The following combinations are spec and RFC compliant: (1) IPv4-in-IPv4 (2) IPv6-in-IPv4 Dino From mrw@sandstorm.net Wed Aug 12 08:54:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBEE23A6803 for ; Wed, 12 Aug 2009 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2l7K-v0XDXL for ; Wed, 12 Aug 2009 08:54:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AB5013A6B42 for ; Wed, 12 Aug 2009 08:54:18 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CFqH2F074506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 11:52:17 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 11:52:15 -0400 References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 15:54:54 -0000 Hi Dino, On Aug 12, 2009, at 11:44 AM, Dino Farinacci wrote: >> I _do_ understand that this means that LISP won't work (at all) >> when used through the aforementioned buggy NAT boxes. But, it >> isn't clear to me that LISP can work through those NAT boxes, >> anyway. Nor is it clear to me why we would care to place this >> requirement on LISP (that it work through NAT boxes), any more than >> we care whether it >> works through IPv4/IPv6 translators. > > Let me make this crystal clear. > > (1) LISP does work through NATs today. We have an existence proof, > many of the boxes on the LISP network > are behind NATs. Could you explain what configuration is needed to make this work? > (2) LISP *is* compliant with RFCs regarding 0 UDP-checksuming when > IPv4 is the outer header. It is _not_ RFC compliant to ignore non-zero UDP checksums in either IPv4 or IPv6. So, the behavior described in the LISP document is _not_ RFC compliant for IPv4 or IPv6 at this point, nor will it be when you change the text to indicated that the ETR _MAY_ ignore non- zero UDP checksums. The current RFCs require that receiving nodes _check_ non-zero UDP checksums. This is just a fact, and I don't really understand how we could be arguing about it. It may be the case that there are good reasons for LISP to behave as it does. If so, we need to document those reasons very clearly and get IETF consensus that ignoring non-zero UDP checksums is a reasonable thing to do in this case. Margaret From Fred.L.Templin@boeing.com Wed Aug 12 09:14:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D023A6BA3 for ; Wed, 12 Aug 2009 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS-t6Ckq9FDP for ; Wed, 12 Aug 2009 09:14:55 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 4E7FF3A6A5D for ; Wed, 12 Aug 2009 09:14:55 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7CGBYsi012356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Aug 2009 09:11:34 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7CGBYXl025832; Wed, 12 Aug 2009 09:11:34 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7CGBXNR025758; Wed, 12 Aug 2009 09:11:34 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:11:33 -0700 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: Wed, 12 Aug 2009 09:11:33 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10645539E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [#4] Re: [lisp] LISP errors Thread-Index: AcobMW/5HSIP4ybsQCu/iomMOdGTRgAMk+cQ References: <49F02E91.8050209@firstpr.com.au><2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com><20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Sam Hartman" X-OriginalArrivalTime: 12 Aug 2009 16:11:33.0682 (UTC) FILETIME=[8F837920:01CA1B67] Cc: lisp@ietf.org Subject: Re: [lisp] [#4] Re: LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:14:56 -0000 Sam, I was going to post this on a new subject heading, but your message has given me an appropriate platform since it calls for a new LISP error for handling MTU as follows: 1) Let the ITR encapsulate all IPv6 packets and all IPv4 packets with DF=3D1 in the UDP/LISP headers and an outer IPv4 header with DF=3D0. The ITR then sends the encapsulated packet into the tunnel as long as it is smaller than the cached MTU value (see step 3). 2) If the ETR receives the first-fragment of a fragmented IPv4/UDP/LISP packet, it sends a LISP "Too Big" error message back to the ITR that tells the ITR it is sending packets that are too large. The ETR otherwise discards all IPv4 fragments, i.e., it does not perform IPv4 reassembly (gasp!). 3) Upon receiving a LISP "Too Big" message from an ETR, the ITR caches the size reported in the message and uses it to determine when to admit future packets into the tunnel vs when to drop them and return an ICMP PTB (see step 1). So, this is both a revision to the MTU handling discipline as well as a call for a new LISP error message type (the LISP "Too Big" message). Comments? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, August 12, 2009 2:44 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: [#4] Re: [lisp] LISP errors >=20 > >>>>> "Templin," =3D=3D Templin, Fred L writes: >=20 > Templin,> In addition to errors that may occur along the path from > Templin,> the ITE to the ETE *before* decapsulation and errors > Templin,> that may occur along the path from the ETE to the final > Templin,> destination *after* decapsulation, errors may also occur > Templin,> *during* decapsulation. An example is what if the ETR > Templin,> decapsulates the outer IP header, but the inner IP stack > Templin,> is not configured? (Answer is that the ITR should > Templin,> receive an error by which it can ascertain that this ETR > Templin,> is having trouble, and should start using a different > Templin,> ETR instead.) >=20 > Templin,> This gives rise to a type of error message that is > Templin,> neither fish nor fowl, i.e., it is neither an RLOC-based > Templin,> nor an EID-based ICMP error - it is a *LISP* error > Templin,> instead. One approach is to have the ETR send such a > Templin,> LISP error back to the ITR with enough identifying > Templin,> credentials such that the ITR can be reasonably sure the > Templin,> message is authentic. The message should further not be > Templin,> dropped by packet filters on the path from the ETR to > Templin,> the ITR that filter "naked" ICMP messages. >=20 > Fred, this is opened as issue #4. > I've attached the following chair note to the issue: >=20 > Fred opened this issue before the issue tracker was available. > Discussion on the list suggested that Fred's original conception might > not have WG consensus, but the general problem of when LISP should > send errors and how this should be done definitely is an open issue. From dmm@1-4-5.net Wed Aug 12 09:24:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166DB3A6B97 for ; Wed, 12 Aug 2009 09:24:08 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmIMIB5dVoDd for ; Wed, 12 Aug 2009 09:23:52 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 661BF3A6A2B for ; Wed, 12 Aug 2009 09:23:52 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n7CGLejF029678; Wed, 12 Aug 2009 09:21:40 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n7CGLedw029677; Wed, 12 Aug 2009 09:21:40 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 12 Aug 2009 09:21:40 -0700 From: David Meyer To: Margaret Wasserman Message-ID: <20090812162140.GA29273@1-4-5.net> References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:24:08 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >> (1) LISP does work through NATs today. We have an existence proof, =20 >> many of the boxes on the LISP network >> are behind NATs. > > Could you explain what configuration is needed to make this work? Its actually pretty simple. You need to tell ITRs how to reach the ETR that is behind the NAT; as normal, the outside world reaches devices that are behind the NAT by using whatever the "outside address" is on the NAT. So the ETR behind the NAT needs to provide that address in its map-reply messages.=20 In practice, you would configured something like ip lisp database-mapping p 1 w 100=20 or whatever syntax your implementation uses. Of course, the isn't an interface on the ETR, but this is easily remedied by configuring a loopback interface with this address. =20 BTW, all of this can be automated in the same way the name to outside address binding for the NAT is automated with dynamic DNS.=20 Dave =09 --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqC7BQACgkQORgD1qCZ2KcH/ACgib5FkcRbE3eSF7uL+P/PY2Fl pUgAn3EKYHgSKsGCm9EraEIUWeuEojd5 =nHQT -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From hartmans@mit.edu Wed Aug 12 09:24:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEDF3A6BC5 for ; Wed, 12 Aug 2009 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWEcyZkLWynH for ; Wed, 12 Aug 2009 09:24:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id DDA873A6BD4 for ; Wed, 12 Aug 2009 09:24:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8946A51C6; Wed, 12 Aug 2009 12:23:51 -0400 (EDT) To: "Templin\, Fred L" References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A10645539E@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Wed, 12 Aug 2009 12:23:51 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10645539E@XCH-NW-7V2.nw.nos.boeing.com> (Fred L. Templin's message of "Wed\, 12 Aug 2009 09\:11\:33 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#4] Re: LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:24:36 -0000 >>>>> "Templin," == Templin, Fred L writes: Templin,> Sam, I was going to post this on a new subject heading, Templin,> but your message has given me an appropriate platform Templin,> since it calls for a new LISP error for handling MTU as Templin,> follows: Fred, this is definitely off topic for this thread and is very close to reopening an issue that the working group has closed. I strongly suggest that you find someone to bring any MTU issues that you may still have to the WG in their own words with particular emphasis on what the problem is rather than the solution. Sam Hartman LISP co-chair From olivier.bonaventure@uclouvain.be Wed Aug 12 09:30:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5D53A6B94 for ; Wed, 12 Aug 2009 09:30:42 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOLqEObCC0J5 for ; Wed, 12 Aug 2009 09:30:42 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id D5CD63A698E for ; Wed, 12 Aug 2009 09:30:41 -0700 (PDT) Received: from mbpobo.local (ip-80-236-248-173.dsl.scarlet.be [80.236.248.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E7DABF236B; Wed, 12 Aug 2009 10:30:10 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be E7DABF236B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1250065811; bh=Ep1nPWJlASrTiXRR3aZhuNV5A7woPzgRRQWbj10iEDQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JR6vAE3fSutKyYNL+BPL1P0ZjEyW4Mw8R/jDXTh9D/c/vanQr6ncrBqDiuCjmA90d W6rDAgKFwqYpHkhFuHwyz8y3ao2Q54bXP9WS34OuNR4oYk7kr4tSdTfU4YM5729uEC TM3G7QOOk8f05G0iRITML6adJzQNjuQRGfBkCGko= Message-ID: <4A827D8D.8020508@uclouvain.be> Date: Wed, 12 Aug 2009 10:30:05 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Sam Hartman References: <4A81E618.9080801@uclouvain.be> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E7DABF236B.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 12 Aug 2009 16:30:42 -0000 Sam, > >> > >> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H > >> with MD5 preshared keys as the mandatory to implement mechanism > >> between an ETR and a map server . > > Olivier> I agree with you that this is unlikely to be the best > Olivier> standardised solution to authenticate the exchange > Olivier> between an ETR and a map server. However, as for issue > Olivier> #3, I think that we should first define whether we > Olivier> consider that LISP should work correctly even if there is > Olivier> - an on-path attack - only off-path attacks > > Olivier> Once we have decided the capabilities of our target > Olivier> attacker, then we can discuss the mechanisms that need to > Olivier> be used to counter such attackers. > > > I can see your point for #3. However for #2, I disagree, because what > we have is very clearly not good enough to get published in the IETF > at all. I agree that RFC2402 H with MD5 preshared keys is not a good solution and should be removed from the draft. However, it is too early to discuss a particular security mechanism. The ETR-MS segment is not the most problematic segment from a security viewpoint. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From dino@cisco.com Wed Aug 12 09:40:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102513A6A6C for ; Wed, 12 Aug 2009 09:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DDtPHARgsPw for ; Wed, 12 Aug 2009 09:40:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9C6883A6C28 for ; Wed, 12 Aug 2009 09:40:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIuMgkqrR7PE/2dsb2JhbAC6WIgrkRAFhBk X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="194905331" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2009 16:39:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGdFtV031835; Wed, 12 Aug 2009 09:39:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGdF9P013559; Wed, 12 Aug 2009 16:39:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:39:15 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:39:15 -0700 Message-Id: From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4A827D8D.8020508@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 09:39:14 -0700 References: <4A81E618.9080801@uclouvain.be> <4A827D8D.8020508@uclouvain.be> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:39:15.0362 (UTC) FILETIME=[6DF3B820:01CA1B6B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1825; t=1250095155; x=1250959155; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20management=20and=20security=2 0mechanism |Sender:=20; bh=jYlngbqRZHZhhPuXxms82mUNJ9usopmsdDWmAwV3r7k=; b=m5QAarpTN+24xSHWfVrlH8WpwJVfzQP8csTKXQTqqOd1KE+LECysXINQgD NP0Nd0q9BvVBVVnqZm7iELo3ZN2VhJdBjTeAa+9SHoxd3WpOjLSr1iPTdbVZ 1IBoWc5j8r; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:40:09 -0000 The solution works and is simple. We have been using it for a while. We are doing experiments. The LISP working group is chartered for experimental RFC, so we don't have to dot the Is and cross the Ts at this point in time. Please, oh please. Let's keep this working group practical. Dino On Aug 12, 2009, at 1:30 AM, Olivier Bonaventure wrote: > Sam, >>>> >>>> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H >>>> with MD5 preshared keys as the mandatory to implement mechanism >>>> between an ETR and a map server . >> >> Olivier> I agree with you that this is unlikely to be the best >> Olivier> standardised solution to authenticate the exchange >> Olivier> between an ETR and a map server. However, as for issue >> Olivier> #3, I think that we should first define whether we >> Olivier> consider that LISP should work correctly even if there is >> Olivier> - an on-path attack - only off-path attacks >> >> Olivier> Once we have decided the capabilities of our target >> Olivier> attacker, then we can discuss the mechanisms that need to >> Olivier> be used to counter such attackers. >> >> >> I can see your point for #3. However for #2, I disagree, because >> what >> we have is very clearly not good enough to get published in the IETF >> at all. > > I agree that RFC2402 H with MD5 preshared keys is not a good solution > and should be removed from the draft. However, it is too early to > discuss a particular security mechanism. The ETR-MS segment is not the > most problematic segment from a security viewpoint. > > > Olivier > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Wed Aug 12 09:47:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9C73A6C22 for ; Wed, 12 Aug 2009 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZYsXGn+aCim for ; Wed, 12 Aug 2009 09:47:37 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id AE7C53A6C15 for ; Wed, 12 Aug 2009 09:47:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 1725FA383D for ; Wed, 12 Aug 2009 09:46:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD1704301B3; Wed, 12 Aug 2009 09:45:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 18E4E43011B; Wed, 12 Aug 2009 09:45:42 -0700 (PDT) Message-ID: <4A82F1B5.3060804@joelhalpern.com> Date: Wed, 12 Aug 2009 12:45:41 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dino Farinacci References: <4A81E618.9080801@uclouvain.be> <4A827D8D.8020508@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:47:38 -0000 I think Sam has a fair concern here. If you wanted to claim "this is an experiment, no one will attack it, so we are not securing any of the links" then we could have something to discuss. (I think folks would aruge that doing a decent job is definable and deployable, but we could have the discussion.) But, to say "yes, we need some security" and then adopt something that is known to be too weak, and not designed to let you experiment with other approaches (you mandate a specific mechanism), is difficult to defend. Practical is important. But it does not justify making bad security choices. Yours, Joel Dino Farinacci wrote: > The solution works and is simple. We have been using it for a while. > > We are doing experiments. The LISP working group is chartered for > experimental RFC, so we don't have to dot the Is and cross the Ts at > this point in time. > > Please, oh please. Let's keep this working group practical. > > Dino > > On Aug 12, 2009, at 1:30 AM, Olivier Bonaventure wrote: > >> Sam, >>>>> >>>>> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H >>>>> with MD5 preshared keys as the mandatory to implement mechanism >>>>> between an ETR and a map server . >>> >>> Olivier> I agree with you that this is unlikely to be the best >>> Olivier> standardised solution to authenticate the exchange >>> Olivier> between an ETR and a map server. However, as for issue >>> Olivier> #3, I think that we should first define whether we >>> Olivier> consider that LISP should work correctly even if there is >>> Olivier> - an on-path attack - only off-path attacks >>> >>> Olivier> Once we have decided the capabilities of our target >>> Olivier> attacker, then we can discuss the mechanisms that need to >>> Olivier> be used to counter such attackers. >>> >>> >>> I can see your point for #3. However for #2, I disagree, because what >>> we have is very clearly not good enough to get published in the IETF >>> at all. >> >> I agree that RFC2402 H with MD5 preshared keys is not a good solution >> and should be removed from the draft. However, it is too early to >> discuss a particular security mechanism. The ETR-MS segment is not the >> most problematic segment from a security viewpoint. >> >> >> Olivier >> -- >> http://inl.info.ucl.ac.be , UCLouvain, Belgium >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From hartmans@mit.edu Wed Aug 12 09:52:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A695D3A6C47 for ; Wed, 12 Aug 2009 09:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAKoIfkBxrPV for ; Wed, 12 Aug 2009 09:52:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id F07723A6C52 for ; Wed, 12 Aug 2009 09:52:32 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2CB6A641DA; Wed, 12 Aug 2009 12:43:28 -0400 (EDT) To: Dino Farinacci References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> From: Sam Hartman Date: Wed, 12 Aug 2009 12:43:28 -0400 In-Reply-To: <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> (Dino Farinacci's message of "Wed\, 12 Aug 2009 08\:22\:59 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, fred@cisco.com, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:52:33 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: >> You'd need to word it as an ITR MAY send a zero checksum, an >> ETR MUST accept a 0 checksum and MAY ignore the checksum >> completely. And of Dino> Anyone object to me putting this text in the -04 spec now? Dino> Then, could we close this issue? Well, you haven't yet opened the issue, which makes closing it difficult.:-) However this only addresses part of the issue raised. You'll also need to add a normative reference to Marshall's document or some other document that updates the RFCs to make your behavior permitted. I'd prefer that we make all the changes related to an issue like this at once, but that's a fairly mild preference. If you do make this change but not add the normative reference, then leave the issue open, but note this change in a comment. From dino@cisco.com Wed Aug 12 09:52:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0B73A6C47 for ; Wed, 12 Aug 2009 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKRyAxMDpwYN for ; Wed, 12 Aug 2009 09:52:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 67BE93A6BA3 for ; Wed, 12 Aug 2009 09:52:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOOOgkqrR7MV/2dsb2JhbAC6VYgrkRIFhBk X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="194910463" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2009 16:49:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGn8B6028946; Wed, 12 Aug 2009 09:49:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGn8o6020429; Wed, 12 Aug 2009 16:49:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:49:07 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:49:07 -0700 Message-Id: <72EA18A6-6457-4BD0-8B54-9DE93716706F@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A82F1B5.3060804@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 09:49:07 -0700 References: <4A81E618.9080801@uclouvain.be> <4A827D8D.8020508@uclouvain.be> <4A82F1B5.3060804@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:49:07.0713 (UTC) FILETIME=[CF054F10:01CA1B6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=209; t=1250095748; x=1250959748; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=09management=20and=20security=2 0mechanism |Sender:=20; bh=T91sv0SA58kAGFpp4ftPVEIc+51XMpHIbxgA+rzfIds=; b=iHTrOFA4l7Xv5HBDej0eCwxQnPmZDFNj6JB9Sm3SJk+0ImISPm90UGVz5L fhyYhBqb76jVaMWQH4Hi3akApVcn0YVpKTOLLTV4KtvL3SQBpsuIL+rgIapJ mAekT19ESDMn+ASuE7Sp8qGDZfH99DzhazLmce1Z1SomD4EmeIM6M=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:52:34 -0000 > Practical is important. But it does not justify making bad security > choices. The way we do MD5 or SHA-* authentication with the AH header for Map- Registers is not a bad security choice. Dino From dino@cisco.com Wed Aug 12 09:55:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD3C3A6BD7 for ; Wed, 12 Aug 2009 09:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5PcWa35WkQs for ; Wed, 12 Aug 2009 09:55:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9BC4D3A6AD0 for ; Wed, 12 Aug 2009 09:55:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANKPgkqrR7PD/2dsb2JhbAC6WIgrkRIFgi2BbIoX X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="227044079" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 16:51:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGpkCc013178; Wed, 12 Aug 2009 09:51:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGpj7S028157; Wed, 12 Aug 2009 16:51:46 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:51:45 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:51:45 -0700 Message-Id: <2E1CB9BB-E716-461C-913E-BC1631D74B54@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 09:51:45 -0700 References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:51:45.0559 (UTC) FILETIME=[2D1AB270:01CA1B6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=714; t=1250095906; x=1250959906; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=DhClOusrAyQK19HN0FRhfGekUMvbWUIVVoQqR/DPReU=; b=QKhwNgRj+2DpdsZIgwqDqZsZSQVLWGfM2sI7x1Tl40wxc08OucsvnQi3qm aXQBa/cYeslJSehhvkvWIRtxV/WN7osK8+E0L0flToCJkNeQAU4+6f/yQ3G9 igqiB6pPuA; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org, fred@cisco.com, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:55:06 -0000 > Well, you haven't yet opened the issue, which makes closing it > difficult.:-) > > However this only addresses part of the issue raised. You'll also > need to add a normative reference to Marshall's document or some other > document that updates the RFCs to make your behavior permitted. > > I'd prefer that we make all the changes related to an issue like this > at once, but that's a fairly mild preference. If you do make this > change but not add the normative reference, then leave the issue open, > but note this change in a comment. I am so confused with this process that I'm going to ask you to contribute text to me and I will include it. Issue closed in my mind for now. Dino From mrw@sandstorm.net Wed Aug 12 09:58:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A703A67FC for ; Wed, 12 Aug 2009 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VStaB50+8u3H for ; Wed, 12 Aug 2009 09:58:13 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3B8F33A6BD7 for ; Wed, 12 Aug 2009 09:58:12 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CGvMM6077554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 Aug 2009 12:57:22 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <78BC5FA4-7DFE-42C1-9BD9-51F163127176@sandstorm.net> From: Margaret Wasserman To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 12:57:21 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:58:14 -0000 I have been doing some web searches to determine what the implementation and deployment state is for IPv6 UDP checksum offload hardware and software, and I thought I would share my early findings as data for our discussions. Unfortunately (for our purposes), IPv6 UDP checksum offload seems to be very widely implemented and deployed. Based on my web surfing, IPv6 UDP checksum offload is supported in the following operating systems (not an exhaustive list): Windows XP and Vista with NDIS 6.x and higher (maybe in NDIS 5.x, sources are ambiguous) Mac OS X and higher Free BSD 4.5 and higher Linux (I was not able to determine when this was added, and to which distributions) There is some indication that Solaris 10 may support IPv6 UDP checksum offload, not confirmed by anything on the Sun site, though. There are also many NICs that support UDP checksum offload for IPv6. It is not possible to tell, from their web sites, how they handle inbound zero checksums in IPv6, but it is very likely that at least some of them are implemented to correctly flag those packets as having a bad UDP checksum. On some of these systems, it only seems to be possible to separately configure rx and tx chekcsum offloading. On many of these systems, it is possible to separately control whether checksum offloading is enabled for: IPv4 header rx checksum, IPv4 header tx checksum, UDP rx checksum, UDP tx checksum, TCP rx checksum, TCP tx checksum. On some of these systems, it appears that you can separate control UDP and TCP checksum offloading for IPv4 and IPv6. In none of these systems is it possible to control UDP tx or rx checksum offloading for a single UDP protocol. Margaret From dino@cisco.com Wed Aug 12 09:58:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC5F28C0D7 for ; Wed, 12 Aug 2009 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m8o4cAN5gMj for ; Wed, 12 Aug 2009 09:58:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C7D5B28C0D9 for ; Wed, 12 Aug 2009 09:58:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP+QgkqrR7MV/2dsb2JhbAC6RYgrkRAFhBmBUYhG X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="227048390" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 16:57:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGvuoh016141; Wed, 12 Aug 2009 09:57:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGvung003839; Wed, 12 Aug 2009 16:57:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:56 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:55 -0700 Message-Id: <55688DEC-6581-471A-9B00-68D6D429B9C5@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 09:57:55 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:57:55.0707 (UTC) FILETIME=[09BACCB0:01CA1B6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1000; t=1250096276; x=1250960276; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20=20management=20and=20securit y=20mechanism |Sender:=20; bh=WcoAY2xaqUAnEmUmXQO6V0MpFCMxpHMyviltffG1eDI=; b=vG4Go5TrxHo2zsxAQ3Inhq8jpE5+0L83DxPCMU8xdenyYlEwf6A8VOUfSv 0S+eau1PtOJtRbWZW5AuLdhc6gwIOgXFG3KYDZlEfAQExGVwh3Fi5+86wOQi Rmq62IuwqVSYcQwEkLbzlCNL7zWcFVaKGoy+yMorkgvF+3MDAOiAA=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 16:58:52 -0000 > * IPsec (IKEV2 + esp null) > > May interact poorly with other uses of IPsec on the same device. > Fairly difficult to standardize; there are a lot of tricky bits to > specify. May end up involving more state than TLS between the PAD > entry, the SPD entry, and the SAD entry. > > I can't think of any success stories with this approach. OSPF V3 does > this, but I think both the security community and the routing > community were vaguely unhappy with the results. Well I am happy with the results we have on our test LISP network. It is: (1) Easy to configure (2) Stateless (3) No overhead (i.e. no TCP connections to keep up) (4) Easy to rekey at any point. (5) No chit-chat before getting the data you need to get from the ETR to the map-server. That is, using HMACs transmitted in AH headers. It is simple and it works. We have running code that proves it. There is no reason to change it. We need to focus on other more important issues with LISP. Dino From mrw@sandstorm.net Wed Aug 12 10:12:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5902A3A69D4 for ; Wed, 12 Aug 2009 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V10SP7Xswrfc for ; Wed, 12 Aug 2009 10:12:58 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 714423A68BE for ; Wed, 12 Aug 2009 10:12:58 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CHAXJI078105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 13:10:33 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Dino Farinacci In-Reply-To: <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 13:10:33 -0400 References: <20090812000815.6D2A06BE5CC@mercury.lcs.mit.edu> <3FB04D1B-83CE-4A22-BC4B-A067C4BB15B4@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org, fred@cisco.com, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 17:12:59 -0000 Hi Dino, On Aug 12, 2009, at 11:22 AM, Dino Farinacci wrote: > On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: > >> You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST >> accept a 0 checksum and MAY ignore the checksum completely. And of > > Anyone object to me putting this text in the -04 spec now? > > Then, could we close this issue? I missed this question the first time... I sent seven separate issues to the list that I gleaned from the UDP checksum discussion. Some were mine, and some were raised by other people... I would be comfortable closing two of those issues based on your suggested text update, but I can't tell you the issue numbers to close until they are in the database. They were issues #2 and #4 in my list. Margaret From mrw@sandstorm.net Wed Aug 12 10:29:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09D63A6C34 for ; Wed, 12 Aug 2009 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bRAofYR-Gk4 for ; Wed, 12 Aug 2009 10:29:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5287F3A6B94 for ; Wed, 12 Aug 2009 10:29:14 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CH6YxR077930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 13:06:34 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1FC87CE1-B3C5-42A6-BF13-4931ABECFCEC@sandstorm.net> From: Margaret Wasserman To: David Meyer In-Reply-To: <20090812162140.GA29273@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 13:06:33 -0400 References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> <20090812162140.GA29273@1-4-5.net> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 17:29:54 -0000 Thanks, Dave. A few further questions... On Aug 12, 2009, at 12:21 PM, David Meyer wrote: >>> (1) LISP does work through NATs today. We have an existence proof, >>> many of the boxes on the LISP network >>> are behind NATs. >> >> Could you explain what configuration is needed to make this work? > > Its actually pretty simple. You need to tell ITRs how to > reach the ETR that is behind the NAT; as normal, the > outside world reaches devices that are behind the NAT by > using whatever the "outside address" is on the NAT. So > the ETR behind the NAT needs to provide that address in > its map-reply messages. > > In practice, you would configured something like > > ip lisp database-mapping p 1 w 100 > > or whatever syntax your implementation uses. Of course, > the isn't an interface on the ETR, but > this is easily remedied by configuring a loopback > interface with this address. > > BTW, all of this can be automated in the same way the > name to outside address binding for the NAT is automated > with dynamic DNS. This makes sense, as far as it goes... So, if the outside address changes, how would the devices sending the map requests know to reach the ETR at the new address? If it used the DNS to get the address of the ETR originally, how will it know that it should re-try DNS? How would the ETR know to start using the new address in its mapping replies? If the ITR inside the NAT sends a mapping request and the mapping reply comes back directly from the remote ETR, not from the mapping server, how does that reply reach the ITR behind the NAT? Margaret From gjshep@gmail.com Wed Aug 12 11:44:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF5C3A6994 for ; Wed, 12 Aug 2009 11:44:48 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-WevzEMsZ2L for ; Wed, 12 Aug 2009 11:44:47 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 4EFD43A67DB for ; Wed, 12 Aug 2009 11:44:47 -0700 (PDT) Received: by qyk41 with SMTP id 41so208651qyk.29 for ; Wed, 12 Aug 2009 11:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Dv5JoL9W5VmrCHDj4ajq3bitQuDKu+uI+uHW7cCZPZs=; b=cpMgmKcit81W1vLfhOXL6q/PjN7WS1KkzCe1CBV4M3VeRVYCFVKUm7YAlM+u6Lp9BW ZCcscvWKpeerGrAOY/h66WXw5hwTXRLLt/tkcjpjuf+mnWCDQYAkDSlYX+vPdaim0dhX /RovXkYD0T+JaZTI3V4wFq5WDMvu41Gq+erfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=KfHOOrX5Waz1n0OftCokLUl0YGmMjAYTIp54LcLKRtMJGJn1DEHJK7Of3QfwVq5p8b 11/YyHHhf8cMVjp0bu7t/dU3Zxh9iViXXKAlv7he9H2jH/SfDQxXsFBT9hgrt3E9ue8F t7b4iL/HVs3sCpKBgEAUinWsxM+E+loYrJZ5c= MIME-Version: 1.0 Received: by 10.229.41.13 with SMTP id m13mr526495qce.85.1250102593445; Wed, 12 Aug 2009 11:43:13 -0700 (PDT) Date: Wed, 12 Aug 2009 11:43:13 -0700 Message-ID: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> From: Greg Shepherd To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com 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, 12 Aug 2009 18:44:48 -0000 > It is _not_ RFC compliant to ignore non-zero UDP checksums in either IPv4 or IPv6. Margret, Which RFC are you referring to for IPv4? >From RFC768 I find: "Fields" "If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care)." It almost reads as if Postel had LISP in mind when he wrote this. ;-) Now we just need to fix IPv6 and we're golden. Greg > So, the behavior described in the LISP >document is _not_ RFC compliant for IPv4 or IPv6 at this point, nor will it be when you > change the text to indicated that the ETR >_MAY_ ignore non- zero UDP checksums. The current RFCs require that receiving > nodes _check_ non-zero UDP checksums. >This is just a fact, and I don't really understand how we could be arguing about it. > > It may be the case that there are good reasons for LISP to behave as it does. If so, we need to document those reasons very > clearly and get IETF consensus that ignoring non-zero UDP checksums is a reasonable thing to do in this case. > > Margaret From mrw@sandstorm.net Wed Aug 12 12:29:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32323A6A01 for ; Wed, 12 Aug 2009 12:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95zWHO4zXjxq for ; Wed, 12 Aug 2009 12:29:36 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 162533A6A6F for ; Wed, 12 Aug 2009 12:29:10 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CJQmV6084511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 15:26:48 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> From: Margaret Wasserman To: gjshep@gmail.com In-Reply-To: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 15:26:47 -0400 References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 19:29:36 -0000 Hi Greg, On Aug 12, 2009, at 2:43 PM, Greg Shepherd wrote: >> It is _not_ RFC compliant to ignore non-zero UDP checksums in >> either IPv4 or IPv6. > > Margret, > > Which RFC are you referring to for IPv4? > > From RFC768 I find: > > "Fields" > > "If the computed checksum is zero, it is transmitted as all ones (the > equivalent in one's complement arithmetic). An all zero transmitted > checksum value means that the transmitter generated no checksum (for > debugging or for higher level protocols that don't care)." > > It almost reads as if Postel had LISP in mind when he wrote this. ;-) > > Now we just need to fix IPv6 and we're golden. Not quite... It isn't the sending of zero UDP checksums in IPv4 that is non-compliant, it is what the LISP ETR is required to do when receiving them. The current LISP specification requires ETRs to _all_ UDP checksums received in the outer header of encapsulated data packets, not just ones that are set to zero. So, even if the ITR did calculate a checksum and insert a non-zero value into the UDP checksum field, the receiving ETR would not check it. RFC 768 is silent on the issue of what level of UDP checksum support is required on IPv4 systems, but RFCs 1122 (requirements for internet hosts) and 1812 (requirements for internet routers) both require that IPv4 nodes that implement UDP include support for checking non-zero UDP checksums in received packets. We decided earlier in this discussion that a LISP node is a router not a host, so RFC 1812 would apply. It says (among many other things): " Although a particular application protocol may require that UDP datagrams it receives must contain a UDP checksum, there is no general requirement that received UDP datagrams contain UDP checksums. Of course, if a UDP checksum is present in a received datagram, the checksum must be verified and the datagram discarded if the checksum is incorrect." So, to comply with RFC 1812, the LISP ETR would need to verify non- zero checksums and discard the datagram if the checksum incorrect. There are two things that we are trying to do here: - Avoid the performance overhead of calculating UDP checksums. The current spec proposes we do this by having ITRs set the UDP checksums in the outer headers LISP encapsulated data packets to zero. This is fine in IPv4, compliance-wise, but is forbidden by RFC 2460. Marshall Eubanks has a draft out to allow this in IPv6, as well. - Make LISP work across widely-deployed, buggy NAT boxes that overwrite zero UDP checksums with invalid values. The proposal in the LISP spec is to accomplish this by having LISP ETRs ignore all UDP checksums, even non-zero ones. As far as I can tell, we have three reasonable choices for what to do to bring LISP and the IETF standards into line: (1) Decide that it is not that important for LISP to work across those buggy NAT boxes (or that other things are more important), AND convince the IETF that is okay to send zero UDP checksums in IPv6. or (2) Convince the IETF that it is okay to send zero UDP checksums in IPv6 AND that it is okay to ignore non-zero UDP checksums (in IPv4 and IPv6). or (3) Use a different LISP encapsulation (UDP-Lite or IP-in-IP) for both IPv4 and IPv6. Unfortunately, choice three is unpalatable to many of us, because we want LISP to work with legacy LAG/ECMP systems that can only calculate their load-balancing has based on the IP addresses, the IP protocol/ next-header field and TCP or UDP ports. So, we're basically stuck between a rock and a couple of hard places, and the WG needs to decide what to do... Margaret From hartmans@mit.edu Wed Aug 12 13:02:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB3C3A6BA3 for ; Wed, 12 Aug 2009 13:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEA5TNvK6wiM for ; Wed, 12 Aug 2009 13:02:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 27FC63A67B7 for ; Wed, 12 Aug 2009 13:02:22 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0165551C6; Wed, 12 Aug 2009 15:51:03 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Wed, 12 Aug 2009 15:51:03 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 20:02:22 -0000 Discussion earlier on the list focused on whether there was a need for an explicit lisp protocol version in the header. Several participants argued that LISP could change its port if a new version was needed. This issue tracks that discussion. Unless someone objects by August 20, I'll conclude that the consensus of the WG is that no version is needed. From mrw@sandstorm.net Wed Aug 12 13:34:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144B33A68F8 for ; Wed, 12 Aug 2009 13:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cajsXqU+CdBJ for ; Wed, 12 Aug 2009 13:34:58 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 88FAB3A6E39 for ; Wed, 12 Aug 2009 13:34:23 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CKWrLl087647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 16:32:54 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 16:32:53 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 20:34:59 -0000 In this discussion, I indicated that using a new port for a new version of LISP would work (technically), but that I didn't think it was the best choice. In general, I think it is better for a protocol to provide for its own versioning, rather than using up resources associated with a lower-layer protocol. Also, I have been thinking about this a bit more since then, and I wonder about the operational implications of using a new port for each new version of a higher-layer protocol... This means that if a site administrator wants to block (or enable) LISP in his firewall, he would have to keep track of new LISP versions and block (or accept) a new UDP port for each new version of LISP. So, while I'm not strongly religious on this topic, I think it would be better if LISP provided its own versioning field. If we choose to go with the plan that we'll use a new UDP port if we ever need a new version of LISP, I'd like us to explicitly document that, so that it is clear that this was an intentional choice. Margaret On Aug 12, 2009, at 3:51 PM, Sam Hartman wrote: > Discussion earlier on the list focused on whether there was a need for > an explicit lisp protocol version in the header. Several participants > argued that LISP could change its port if a new version was needed. > This issue tracks that discussion. > > Unless someone objects by August 20, I'll conclude that the consensus > of the WG is that no version is needed. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From gjshep@gmail.com Wed Aug 12 13:40:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36963A6BBC for ; Wed, 12 Aug 2009 13:40:56 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7zpgBKXZUOj for ; Wed, 12 Aug 2009 13:40:53 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 3932E28C100 for ; Wed, 12 Aug 2009 13:40:53 -0700 (PDT) Received: by qyk41 with SMTP id 41so282087qyk.29 for ; Wed, 12 Aug 2009 13:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=su9N2pXzXvkhJnMyu1LpzEcvWzUHmBgtjRUxJSM4f/8=; b=MIc4pZKfmGmMzuikz59nMxblFobSBObF7REKJkEAmPS1WiCP1zTLmByaygI+y+oufx 2Ku5N1APmOThji4NJNtXagll3wNvQLWSqtPEnaQyMgjACoBxr1I2BqBM1j4b073sl0/L AjAux36M+SZ3W7bGM1Hjnu8b5wecPYkHyivgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=Ta8rjUz9itG0WAZ6W6YYR/hw7HlytknEYn43reuth5BAU8U2L3XwELtmXUn0wNrH3z l/+tvUvlR7pi5IvAZ6uTSp/oGoxq0g/+uQADYbFoiN60roFcvNcZBKanU/1n/lt37Le8 /PPKcw+oczs2dGQFtgGtvXQ2lZiBtDcO84bfQ= MIME-Version: 1.0 Received: by 10.229.118.6 with SMTP id t6mr609971qcq.39.1250109640956; Wed, 12 Aug 2009 13:40:40 -0700 (PDT) In-Reply-To: <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> Date: Wed, 12 Aug 2009 13:40:40 -0700 Message-ID: <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> From: Greg Shepherd To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com 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, 12 Aug 2009 20:40:58 -0000 On Wed, Aug 12, 2009 at 12:26 PM, Margaret Wasserman wro= te: > > Hi Greg, > > On Aug 12, 2009, at 2:43 PM, Greg Shepherd wrote: > >>> It is _not_ RFC compliant to ignore non-zero UDP checksums in either IP= v4 >>> or IPv6. >> >> Margret, >> >> Which RFC are you referring to for IPv4? >> >> From RFC768 I find: >> >> "Fields" >> >> "If the computed checksum is zero, it is transmitted as all ones (the >> equivalent in one's complement =A0arithmetic). An all zero transmitted >> checksum value means that the transmitter =A0generated =A0no checksum (f= or >> debugging or for higher level protocols that don't care)." >> >> It almost reads as if Postel had LISP in mind when he wrote this. ;-) >> >> Now we just need to fix IPv6 and we're golden. > > Not quite... =A0It isn't the sending of zero UDP checksums in IPv4 that i= s > non-compliant, it is what the LISP ETR is required to do when receiving > them. > > The current LISP specification requires ETRs to _all_ UDP checksums recei= ved > in the outer header of encapsulated data packets, not just ones that are = set > to zero. =A0So, even if the ITR did calculate a checksum and insert a non= -zero > value into the UDP checksum field, the receiving ETR would not check it. An ITR won't do that. IF it did it is violating the LISP spec: "UDP Checksum: this field MUST be transmitted as 0 and ignored on receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. For performance reasons, the ETR MUST ignore the checksum and MUST not do a checksum computation." So let's limit our assumptions to the possible. > RFC 768 is silent on the issue of what level of UDP checksum support is > required on IPv4 systems, but RFCs 1122 (requirements for internet hosts) > and 1812 (requirements for internet routers) both require that IPv4 nodes > that implement UDP include support for checking non-zero UDP checksums in > received packets. =A0We decided earlier in this discussion that a LISP no= de is > a router not a host, so RFC 1812 would apply. It says (among many other > things): > > " Although a particular application protocol may require that UDP > datagrams it receives must contain a UDP checksum, there is no > general requirement that received UDP datagrams contain UDP > checksums. Of course, if a UDP checksum is present in a received > =A0datagram, the checksum must be verified and the datagram discarded > if the checksum is incorrect." > > So, to comply with RFC 1812, the LISP ETR would need to verify non-zero > checksums and discard the datagram if the checksum incorrect. > > There are two things that we are trying to do here: > > - Avoid the performance overhead of calculating UDP checksums. =A0The cur= rent > spec proposes we do this by having ITRs set the UDP checksums in the oute= r > headers LISP encapsulated data packets to zero. =A0This is fine in IPv4, > compliance-wise, but is forbidden by RFC 2460. =A0Marshall Eubanks has a = draft > out to allow this in IPv6, as well. Yes, I'm aware of Marshall's draft. And the motivation for his draft was not LISP but AMT, so you can see the disallowing of zero checksums of an outer header is not unique to LISP. Clearly RFC 2460 overlooked the needs of the community. > - Make LISP work across widely-deployed, buggy NAT boxes that overwrite z= ero > UDP checksums with invalid values. Well, since ITRs send packets to ETRs and ITRs are forbidden from writing non-zero checksums any non-zero chechsum received has been tampered with. We can either assume the entire packet is corrupt and drop it or strip off the outer header and let the forwarding process of the inner header determine the validity of the packet. The later seems the better of the two choices. > The proposal in the LISP spec is to > accomplish this by having LISP ETRs ignore all UDP checksums, even non-ze= ro > ones. I'm not sure if you have a problem with this specifically or just the documentation and IETF process to provide for this. Which is it? > As far as I can tell, we have three reasonable choices for what to do to > bring LISP and the IETF standards into line: > > (1) Decide that it is not that important for LISP to work across those bu= ggy > NAT boxes (or that other things are more important), AND convince the IET= F > that is okay to send zero UDP checksums in IPv6. > > or > > (2) Convince the IETF that it is okay to send zero UDP checksums in IPv6 = AND > that it is okay to ignore non-zero UDP checksums (in IPv4 and IPv6). > > or > > (3) Use a different LISP encapsulation (UDP-Lite or IP-in-IP) for both IP= v4 > and IPv6. > > Unfortunately, choice three is unpalatable to many of us, because we want > LISP to work with legacy LAG/ECMP systems that can only calculate their > load-balancing has based on the IP addresses, the IP protocol/next-header > field and TCP or UDP ports. > > So, we're basically stuck between a rock and a couple of hard places, and > the WG needs to decide what to do... No rock. No hard place. We are the IETF. I think that is what we're doing now, right? Number 2) above seems the best path to me and the current path we are on. Am I missing something here? Thanks, Greg > Margaret > > > From jmh@joelhalpern.com Wed Aug 12 13:41:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C34828C100 for ; Wed, 12 Aug 2009 13:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQIZYrNigH1e for ; Wed, 12 Aug 2009 13:41:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 306DB3A6C27 for ; Wed, 12 Aug 2009 13:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5DF0B430339; Wed, 12 Aug 2009 13:41:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4A05A4301F2; Wed, 12 Aug 2009 13:41:07 -0700 (PDT) Message-ID: <4A8328E1.9@joelhalpern.com> Date: Wed, 12 Aug 2009 16:41:05 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Margaret Wasserman References: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> In-Reply-To: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 20:41:41 -0000 I am actually inclined towards the port number, because I think if we actually need a new version it will be a new protocol. But, having said that, I note that the IANA just sent in an I-D on port number allocation policy indicating that folks should be somewhat cautious about blithely consuming port numbers. Yours, Joel Margaret Wasserman wrote: > > In this discussion, I indicated that using a new port for a new version > of LISP would work (technically), but that I didn't think it was the > best choice. In general, I think it is better for a protocol to provide > for its own versioning, rather than using up resources associated with a > lower-layer protocol. > > Also, I have been thinking about this a bit more since then, and I > wonder about the operational implications of using a new port for each > new version of a higher-layer protocol... This means that if a site > administrator wants to block (or enable) LISP in his firewall, he would > have to keep track of new LISP versions and block (or accept) a new UDP > port for each new version of LISP. > > So, while I'm not strongly religious on this topic, I think it would be > better if LISP provided its own versioning field. > > If we choose to go with the plan that we'll use a new UDP port if we > ever need a new version of LISP, I'd like us to explicitly document > that, so that it is clear that this was an intentional choice. > > Margaret > > On Aug 12, 2009, at 3:51 PM, Sam Hartman wrote: > >> Discussion earlier on the list focused on whether there was a need for >> an explicit lisp protocol version in the header. Several participants >> argued that LISP could change its port if a new version was needed. >> This issue tracks that discussion. >> >> Unless someone objects by August 20, I'll conclude that the consensus >> of the WG is that no version is needed. >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From hartmans@mit.edu Wed Aug 12 13:42:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5B13A6CEE for ; Wed, 12 Aug 2009 13:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAGpXvJp6V7a for ; Wed, 12 Aug 2009 13:42:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 559213A6BBC for ; Wed, 12 Aug 2009 13:42:36 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 57930641DA; Wed, 12 Aug 2009 16:42:00 -0400 (EDT) To: Margaret Wasserman References: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> From: Sam Hartman Date: Wed, 12 Aug 2009 16:42:00 -0400 In-Reply-To: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> (Margaret Wasserman's message of "Wed\, 12 Aug 2009 16\:32\:53 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 20:42:42 -0000 Thanks for refreshing my memory. OK, so we need comments on how to resolve this. Personally, I definitely support the plan of documenting our extensibility choice no matter what it is. From mrw@sandstorm.net Wed Aug 12 14:00:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43493A6948 for ; Wed, 12 Aug 2009 14:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYnDqIF0nfmW for ; Wed, 12 Aug 2009 14:00:46 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 359103A67B2 for ; Wed, 12 Aug 2009 14:00:45 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7CKxtdH088771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 16:59:56 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: gjshep@gmail.com In-Reply-To: <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 12 Aug 2009 16:59:55 -0400 References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Aug 2009 21:00:47 -0000 On Aug 12, 2009, at 4:40 PM, Greg Shepherd wrote: >> >> The current LISP specification requires ETRs to _all_ UDP checksums >> received >> in the outer header of encapsulated data packets, not just ones >> that are set >> to zero. So, even if the ITR did calculate a checksum and insert a >> non-zero >> value into the UDP checksum field, the receiving ETR would not >> check it. > > An ITR won't do that. IF it did it is violating the LISP spec: > > "UDP Checksum: this field MUST be transmitted as 0 and ignored on > receipt by the ETR. Note, even when the UDP checksum is > transmitted as 0 an intervening NAT device can recalculate the > checksum and rewrite the UDP checksum field to non-zero. For > performance reasons, the ETR MUST ignore the checksum and MUST > not > do a checksum computation." > > So let's limit our assumptions to the possible. It is certainly possible that a LISP ETR will receive an encapsulated LISP data packet with a non-zero UDP checksum. The LISP spec documents at least one case where this could happen -- the UDP checksum could be changed by a NAT box or otherwise corrupted in transit. Also, there are a lot of widely-deployed systems that offload the checksum to hardware, and on those systems it may not be possible to turn off checksum calculation for outbound packets. So, those systems will send encapsulated LISP packets with non-zero checksums. Dino has already agreed to change the text for LISP -04 to say: "An ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely." (or something similar from Sam) So, this implies that ITRs may also send non-zero checksums. Personally, I would greatly prefer to retain the ability to enable UDP checksums in LISP, just in case we ever find out that there are significant operational problems caused by our choice to ignore decades of research and experience that indicate that it is a bad idea to do so. >> >> - Avoid the performance overhead of calculating UDP checksums. The >> current >> spec proposes we do this by having ITRs set the UDP checksums in >> the outer >> headers LISP encapsulated data packets to zero. This is fine in >> IPv4, >> compliance-wise, but is forbidden by RFC 2460. Marshall Eubanks >> has a draft >> out to allow this in IPv6, as well. > > Yes, I'm aware of Marshall's draft. And the motivation for his draft > was not LISP but AMT, so you can see the disallowing of zero checksums > of an outer header is not unique to LISP. Clearly RFC 2460 overlooked > the needs of the community. It's quite a bit more complicated that than, if you consider our "community" to include all of the end-users of (non-LISP, non-AMT) UDP applications, whose applications may be disrupted by corrupted and misdirected LISP or AMT packets. > >> - Make LISP work across widely-deployed, buggy NAT boxes that >> overwrite zero >> UDP checksums with invalid values. > > Well, since ITRs send packets to ETRs and ITRs are forbidden from > writing non-zero checksums any non-zero chechsum received has been > tampered with. We can either assume the entire packet is corrupt and > drop it or strip off the outer header and let the forwarding process > of the inner header determine the validity of the packet. The later > seems the better of the two choices. The problems don't really come in if the packet makes it to the right destination with the destination UDP port intact. They come in when that doesn't happen. > >> The proposal in the LISP spec is to >> accomplish this by having LISP ETRs ignore all UDP checksums, even >> non-zero >> ones. > > I'm not sure if you have a problem with this specifically or just the > documentation and IETF process to provide for this. Which is it? I think that the choice to disable UDP checksum for LISP is technically unwise, perhaps even reckless. I also think that it violates some RFCs, but that is a lesser consideration. If the WG does decide that sending IPv6 zero checksums and ignoring non-zero checksums on receipt is the right thing to do, and if the WG can convince the rest of the IETF that they are right, then updating RFCs is a fairly trivial matter. In that case, we'd need Marshall's draft (or something similar) and a draft to update RFC 1812 to say it is okay to ignore non-zero checksums on receipt. There are _reasons_, though, why the current RFCs were written the way they were. There is research and experience that has shown that packets that get corrupted in transit and misdirected to the wrong host or the wrong application cause serious problems. Those problems won't be constrained to LISP or even to nodes that implement LISP. Margaret From gjshep@gmail.com Wed Aug 12 14:17:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF95C3A690C for ; Wed, 12 Aug 2009 14:17:31 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqjgvBcBLebA for ; Wed, 12 Aug 2009 14:17:30 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 7F47D3A67B2 for ; Wed, 12 Aug 2009 14:17:30 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so128934qwi.31 for ; Wed, 12 Aug 2009 14:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZxLd4s3MTenxRYvBBgvOA4aCcqMOFDCBp2S9y2jxbF0=; b=HG4u3orlbpmdZWircTOO1QcVokiJm7YEMN7Iv6XFHcnGwnglpxK9BoYM0FjoITYH6p XBM+2igaWCyvmIkVLUFcpAwAim860qOKIZGqn5cnDdTZhAldbHWMMaDNJ3ktDSteM9CF NL7Adw8iNWjLoLwB0s73a6LAbMNoVZG4vF9m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=ZXh/8w4yozLJR/BQA51O+MMle6Aw7Wwy1ZZi1VI34iJqPsjzufhyTS5qODNLArK6Hx 3AHd1oqaPeaGgHveyAdacv/7cjs5mtCk+4I24JmdOGMBSCzW0JFu/5SrEWrBIsRhJT4v AdPPQIonNDe8Ma159pegkPjpZTd7+6Dm5Xw+s= MIME-Version: 1.0 Received: by 10.229.54.143 with SMTP id q15mr600995qcg.74.1250111778244; Wed, 12 Aug 2009 14:16:18 -0700 (PDT) In-Reply-To: References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> Date: Wed, 12 Aug 2009 14:16:18 -0700 Message-ID: <38c19b540908121416k4d01d4fex55b75860fc89208c@mail.gmail.com> From: Greg Shepherd To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com 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, 12 Aug 2009 21:17:31 -0000 On Wed, Aug 12, 2009 at 1:59 PM, Margaret Wasserman wrot= e: > > On Aug 12, 2009, at 4:40 PM, Greg Shepherd wrote: >>> >>> The current LISP specification requires ETRs to _all_ UDP checksums >>> received >>> in the outer header of encapsulated data packets, not just ones that ar= e >>> set >>> to zero. =A0So, even if the ITR did calculate a checksum and insert a >>> non-zero >>> value into the UDP checksum field, the receiving ETR would not check it= . >> >> An ITR won't do that. IF it did it is violating the LISP spec: >> >> "UDP Checksum: =A0this field MUST be transmitted as 0 and ignored on >> =A0 =A0 receipt by the ETR. =A0Note, even when the UDP checksum is >> =A0 =A0 transmitted as 0 an intervening NAT device can recalculate the >> =A0 =A0 checksum and rewrite the UDP checksum field to non-zero. =A0For >> =A0 =A0 performance reasons, the ETR MUST ignore the checksum and MUST n= ot >> =A0 =A0 do a checksum computation." >> >> So let's limit our assumptions to the possible. > > It is certainly possible that a LISP ETR will receive an encapsulated LIS= P > data packet with a non-zero UDP checksum. True, but that's not what you stated above. I'm both reading and responding in kind. > The LISP spec documents at least one case where this could happen -- the = UDP > checksum could be changed by a NAT box or otherwise corrupted in transit. Which is different than the ETR setting a non-zero checksum as I was addressing above. > Also, there are a lot of widely-deployed systems that offload the checksu= m > to hardware, and on those systems it may not be possible to turn off > checksum calculation for outbound packets. =A0So, those systems will send > encapsulated LISP packets with non-zero checksums. Show me one such system that has a LISP implementation. Again, let's stick with the possible here. We're developing the spec now for LISP implementations to follow. > Dino has already agreed to change the text for LISP -04 to say: > > "An ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY > ignore the checksum completely." =A0(or something similar from Sam) > > So, this implies that ITRs may also send non-zero checksums. Yes, a compromise to put this behind us and move on. :) > Personally, I would greatly prefer to retain the ability to enable UDP > checksums in LISP, just in case we ever find out that there are significa= nt > operational problems caused by our choice to ignore decades of research a= nd > experience that indicate that it is a bad idea to do so. Can you please site such research, specifically for zero checksums in UDP encapsulated headers where the inner header checksum is non-zero? I clearly need to learn more. >>> >>> - Avoid the performance overhead of calculating UDP checksums. =A0The >>> current >>> spec proposes we do this by having ITRs set the UDP checksums in the >>> outer >>> headers LISP encapsulated data packets to zero. =A0This is fine in IPv4= , >>> compliance-wise, but is forbidden by RFC 2460. =A0Marshall Eubanks has = a >>> draft >>> out to allow this in IPv6, as well. >> >> Yes, I'm aware of Marshall's draft. And the motivation for his draft >> was not LISP but AMT, so you can see the disallowing of zero checksums >> of an outer header is not unique to LISP. Clearly RFC 2460 overlooked >> the needs of the community. > > It's quite a bit more complicated that than, if you consider our "communi= ty" > to include all of the end-users of (non-LISP, non-AMT) UDP applications, > whose applications may be disrupted by corrupted and misdirected LISP or = AMT > packets. Have you read draft-eubanks-chimento-6man-00? It says nothing of generic UDP. It is intended to specifically address the UDP encapsulated outer header where the inner header checksum is in fact calculated. Please help me understand how this would affect any application dependent on the inner packet. >>> - Make LISP work across widely-deployed, buggy NAT boxes that overwrite >>> zero >>> UDP checksums with invalid values. >> >> Well, since ITRs send packets to ETRs and ITRs are forbidden from >> writing non-zero checksums any non-zero chechsum received has been >> tampered with. We can either assume the entire packet is corrupt and >> drop it or strip off the outer header and let the forwarding process >> of the inner header determine the validity of the packet. The later >> seems the better of the two choices. > > The problems don't really come in if the packet makes it to the right > destination with the destination UDP port intact. =A0They come in when th= at > doesn't happen. And then they are dropped. End of problem. >>> The proposal in the LISP spec is to >>> accomplish this by having LISP ETRs ignore all UDP checksums, even >>> non-zero >>> ones. >> >> I'm not sure if you have a problem with this specifically or just the >> documentation and IETF process to provide for this. Which is it? > > I think that the choice to disable UDP checksum for LISP is technically > unwise, perhaps even reckless. I believe you do. I just don't yet understand why. Sorry, but I'm trying. Greg > I also think that it violates some RFCs, but that is a lesser considerati= on. > =A0If the WG does decide that sending IPv6 zero checksums and ignoring > non-zero checksums on receipt is the right thing to do, and if the WG can > convince the rest of the IETF that they are right, then updating RFCs is = a > fairly trivial matter. =A0In that case, we'd need Marshall's draft (or > something similar) and a draft to update RFC 1812 to say it is okay to > ignore non-zero checksums on receipt. > > There are _reasons_, though, why the current RFCs were written the way th= ey > were. =A0There is research and experience that has shown that packets tha= t get > corrupted in transit and misdirected to the wrong host or the wrong > application cause serious problems. =A0Those problems won't be constraine= d to > LISP or even to nodes that implement LISP. > > Margaret > From hartmans@mit.edu Wed Aug 12 17:11:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A363A694C for ; Wed, 12 Aug 2009 17:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEW5+WfGCewf for ; Wed, 12 Aug 2009 17:11:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 637A03A6807 for ; Wed, 12 Aug 2009 17:11:06 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6E56051C6; Wed, 12 Aug 2009 20:10:37 -0400 (EDT) To: gjshep@gmail.com References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> <38c19b540908121416k4d01d4fex55b75860fc89208c@mail.gmail.com> From: Sam Hartman Date: Wed, 12 Aug 2009 20:10:37 -0400 In-Reply-To: <38c19b540908121416k4d01d4fex55b75860fc89208c@mail.gmail.com> (Greg Shepherd's message of "Wed\, 12 Aug 2009 14\:16\:18 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 00:11:07 -0000 Greg, I appreciate that you're trying to join the discussion; it is always great to get new people involved. However you're asking people to rehash a lot of ground and to repeat a bunch of things that have been discussed in the last few days. People, including Margaret, Dino and myself have spent a lot of time reading and responding to LISP mail in the last couple of days. Rehashing the arguments yet again doesn't really help. I do have a suggestion for how you could come up to speed anh help us all. It looks like you work at Cisco, so you probably have reasonably good access to the arguments about why it would be nice to send 0 checksums and ignore checksums on receipt. I've often found that when jumping into the discussion it really helps if I try and summarize the position I don't agree with. By the time I can get to a summary that the other side agrees accurately states their position then I find I have a lot more understanding and am much more likely to contribute constructively. I think it would be great if you could help us all out and prepare such a summary. If you don't have time, I completely understand,but if you don't have time, then it's probably best if you sit this discussion out and join us with the next new issue rather than asking us to repeat what we've been saying for the last week. Sam Hartman LISP co-chair From hartmans@mit.edu Wed Aug 12 17:17:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3D13A6807 for ; Wed, 12 Aug 2009 17:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5dngws3LqYN for ; Wed, 12 Aug 2009 17:17:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6A5483A6802 for ; Wed, 12 Aug 2009 17:17:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8751B51C6; Wed, 12 Aug 2009 20:16:25 -0400 (EDT) To: lisp@ietf.org mail-copies-to: never mail-followups-to: hartmans-ietf@mit.edu, darlewis@cisco.com From: Sam Hartman Date: Wed, 12 Aug 2009 20:16:25 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Taking a break from the UDP checksum X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hartmans-ietf@mit.edu, darlewis@cisco.com 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, 13 Aug 2009 00:17:29 -0000 Several people have contacted me saying that the current discussion is very frustrating. I couldn't agree more! We're at each others' throats. Dave and I started a brainstorming session trying to figure out how we could hopefully work better together. I'm really interested in talking off-list with anyone else who has ideas on that. Meanwhile, I think it would be great if we take a step back. I think this discussion has brought up a lot of important issues on all sides of the debate. However somewhere along the line, we all seem to have lost the balance/belief that we're all trying to build a better Internet. We're making suggestions because we believe we're bringing up important issues not because we're trying to slow things down or create obstructions. If someone seems to be making unworkable suggestions, then we are forgetting to understand why they think breaking something we care about is the right decision, or to take the time to explain to them what is unworkable about their proposals. We're getting to hurried and aren't working well together. So, let's take a break, give the authors a chance to actually enter the issues Margaret has requested and any other issues they see brought up on the list. Let's all calm down and we can approach this again in a couple of days, hopefully from a new balanced view. From gjshep@gmail.com Wed Aug 12 18:24:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F943A6D5A for ; Wed, 12 Aug 2009 18:24:56 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOfS6wgnnrHX for ; Wed, 12 Aug 2009 18:24:56 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id CF5DA3A6ED9 for ; Wed, 12 Aug 2009 18:24:55 -0700 (PDT) Received: by qyk41 with SMTP id 41so404895qyk.29 for ; Wed, 12 Aug 2009 18:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dbHHL2AqSFpKsm5AdvoTtWin+mpN05O+TURMlGYhGIA=; b=LWDJSkgORW03zwilytdOAk9R4hB58pStq75HFeSUpAYZnoxzPQZXx10szFcoAIAuua 4khfn61hSVj6Snhn1gGRISEmDbxgDhQ3X7fGEf2mvy5dZAyDw/UkfKWQiXslDZYY6O0d uI2aljfg3/rq4JblDN1n1oEjdL3h3ZLv+I5u0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=kl2F/G2zGqH5fIoqYKDB47lDXpBjY1dNnQS+ALWFuLO40kgitdfDEiznZo12UOmiGi 8NdT2PSHS2H3NIbwBXHdjGhPOdmMWKN1hNb7+0hLVy1iMXWzGD1FzO3GRF208aVufpcK JpjnwESuRdOrGd9XFRVGGhE1S1EOjpNDzUS0I= MIME-Version: 1.0 Received: by 10.229.1.200 with SMTP id 8mr655930qcg.64.1250126631906; Wed, 12 Aug 2009 18:23:51 -0700 (PDT) In-Reply-To: References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> <38c19b540908121340t71eea744td7f7a42cf3f25a0@mail.gmail.com> <38c19b540908121416k4d01d4fex55b75860fc89208c@mail.gmail.com> Date: Wed, 12 Aug 2009 18:23:51 -0700 Message-ID: <38c19b540908121823t709da132wd99144a5e2018e9b@mail.gmail.com> From: Greg Shepherd To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com 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, 13 Aug 2009 01:24:56 -0000 On Wed, Aug 12, 2009 at 5:10 PM, Sam Hartman wrote: > > > Greg, I appreciate that you're trying to join the discussion; it is > always great to get new people involved. =A0However you're asking people > to rehash a lot of ground and to repeat a bunch of things that have > been discussed in the last few days. > > People, including Margaret, Dino and myself have spent a lot of time > reading and responding to LISP mail in the last couple of days. > Rehashing the arguments yet again doesn't really help. I see you have, and I have read the archives. But I've been involved in this discussion since before LISP was a working group as it first came up while trying to take AMT to last call. So my interests cross over a bit as well. > I do have a suggestion for how you could come up to speed anh help us > all. =A0It looks like you work at Cisco, so you probably have reasonably > good access to the arguments about why it would be nice to send 0 > checksums and ignore checksums on receipt. > > I've often found that when jumping into the discussion it really helps > if I try and summarize the position I don't agree with. =A0By the time I > can get to a summary that the other side agrees accurately states > their position then I find I have a lot more understanding and am much > more likely to contribute constructively. I believe I was directly addressing open issues raised by others in the thread. I asked questions. Is that still allowed? > I think it would be great if you could help us all out and prepare > such a summary. Sure. I don't agree with arguments about whether or not the outer header checksum can/should be zero based on issues regarding general UDP header checksum. Thanks, Greg > If you don't have time, I completely understand,but if you don't have > time, then it's probably best if you sit this discussion out and join > us with the next new issue rather than asking us to repeat what we've > been saying for the last week. > > Sam Hartman > LISP co-chair > From shane@castlepoint.net Wed Aug 12 19:53:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1633A6CC6 for ; Wed, 12 Aug 2009 19:53:33 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKex5arkg9-Y for ; Wed, 12 Aug 2009 19:53:32 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4E9B93A6AF3 for ; Wed, 12 Aug 2009 19:53:32 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D29572684EA; Wed, 12 Aug 2009 20:52:30 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-80-228.hlrn.qwest.net [71.215.80.228]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 12 Aug 2009 20:52:30 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.80.228; client-port=3213; syn-fingerprint=65535:55:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Message-Id: <0C61D2FA-DA52-40D9-8CDC-747CFA16ED3C@castlepoint.net> From: Shane Amante To: Margaret Wasserman In-Reply-To: <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 20:52:15 -0600 References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 02:53:33 -0000 Margaret, On Aug 12, 2009, at 13:26 MDT, Margaret Wasserman wrote: [--snip--] > As far as I can tell, we have three reasonable choices for what to > do to bring LISP and the IETF standards into line: > > (1) Decide that it is not that important for LISP to work across > those buggy NAT boxes (or that other things are more important), AND > convince the IETF that is okay to send zero UDP checksums in IPv6. > > or > > (2) Convince the IETF that it is okay to send zero UDP checksums in > IPv6 AND that it is okay to ignore non-zero UDP checksums (in IPv4 > and IPv6). > > or > > (3) Use a different LISP encapsulation (UDP-Lite or IP-in-IP) for > both IPv4 and IPv6. > > Unfortunately, choice three is unpalatable to many of us, because we > want LISP to work with legacy LAG/ECMP systems that can only > calculate their load-balancing has based on the IP addresses, the IP > protocol/next-header field and TCP or UDP ports. I've taken a step back from this discussion for a few days and had a chance to clear my mind and re-focus. In choice #3, you suggest that LISP switch to a different encapsulations for IPv4 and IPv6, such as UDP-lite or IP-in-IP. I'd like to focus on the latter (IP-in-IP) for a moment, specifically when IPv6 is used as the outer encapsulation. AFAICT, if LISP (or any other protocol) is doing IP-in-IPv6, then the outer IPv6 header is not protected by a header checksum[1], correct? Therefore, in the case of IP-in-IPv6, if the outer header is damaged the packet may end up: a) dropped; or, b) delivered to the wrong destination. So, what is different from this case versus UDP-in-IPv6, (where UDP is using 0 checksums)? Putting this another way, should IP- in-IPv6 be deprecated/forbidden, (if it's not already?), because the outer header isn't checksum protected? -shane [1] Perhaps I'm misinformed on this point and, if that's the case, I would certainly welcome a reference to the RFC describing and/or mandating that. I've briefly scanned RFC's 2460 & 2473 and didn't see it addressed there. From mrw@sandstorm.net Wed Aug 12 21:39:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155EC3A682D for ; Wed, 12 Aug 2009 21:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2fjtcj7jFm9 for ; Wed, 12 Aug 2009 21:39:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id AD9B03A6811 for ; Wed, 12 Aug 2009 21:39:49 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7D4cADv007855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Aug 2009 00:38:10 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <65502669-838C-444A-A002-70B0CB57A1DB@sandstorm.net> From: Margaret Wasserman To: Shane Amante In-Reply-To: <0C61D2FA-DA52-40D9-8CDC-747CFA16ED3C@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 00:38:09 -0400 References: <38c19b540908121143m350139f4nd5932078c7ef310d@mail.gmail.com> <3BF49D1E-A78C-47F6-960B-3FBFC6A710B2@sandstorm.net> <0C61D2FA-DA52-40D9-8CDC-747CFA16ED3C@castlepoint.net> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 04:39:51 -0000 Hi Shane, On Aug 12, 2009, at 10:52 PM, Shane Amante wrote: > ussion for a few days and had a chance to clear my mind and re- > focus. In choice #3, you suggest that LISP switch to a different > encapsulations for IPv4 and IPv6, such as UDP-lite or IP-in-IP. I'd > like to focus on the latter (IP-in-IP) for a moment, specifically > when IPv6 is used as the outer encapsulation. AFAICT, if LISP (or > any other protocol) is doing IP-in-IPv6, then the outer IPv6 header > is not protected by a header checksum[1], correct? Yes, that is correct. Because there is no header checksum in IPv6, packets that are tunneled directly in IPv6 will not have any checksum for the outer IPv6 header fields. It would, of course, be possible to add a checksum to the LISP header that includes the IPv6 pseudo-header checksum, if we are concerned about this lack of protection. Unlike the UDP checksum, calculating a checksum of the IPv6 and LISP headers wouldn't require access to more than 128 bytes of the packet. Of course, this option doesn't support the LAC/ECMP hash function, and that makes the IP-LISP-IPv6 approach less desirable than an IP-LISP- UDP-IPv6 approach, all other things being equal. > Therefore, in the case of IP-in-IPv6, if the outer header is damaged > the packet may end up: a) dropped; or, b) delivered to the wrong > destination. So, what is different from this case versus UDP-in- > IPv6, (where UDP is using 0 checksums)? Putting this another way, > should IP-in-IPv6 be deprecated/forbidden, (if it's not already?), > because the outer header isn't checksum protected? Dropped packets aren't really a problem, since that's what will happen when a bad checksum is detected, anyway. If we do the analysis of all the possible misdirections caused by corrupted IPv6, UDP or LISP headers and we find that the only thing that happens is that packets are dropped and/or decapsulated in the wrong place but sent on to the correct destination, then I may not have any technical objection to allowing (MAY), or even recommending (SHOULD) that LISP ITRs use zero checksums (for IPv4 and IPv6) in LISP data packets. I think we still have some analysis to finish before we can be reasonably sure that this is safe to make this recommendation, though. I've run through a number of scenarios so far, and the cases that still concern me include: - What happens when a LISP packet is redirected to the wrong UDP destination port? For example, what would happen if a LISP packet were received on the TFTP port in a LISP xTR during an active TFTP transfer? - What happens when a LISP packet arrives at the wrong ETR? I _think_ it will just be discarded unless the ETR that received it can forward to the inner header destination EID, in which case it will serendipitously be delivered to the final destination, right? I am also concerned about how errors would be detected and handled in this case. - What happens when a LISP packet arrives at the right ETR but appears to come from the wrong destination? We've discussed the possibility of an incorrect "gleaned" mapping, but I haven't fully explored the implications of that situation. I'm also concerned about how errors would be handled in this case. I think I've mentally covered all of the other cases and determined that the packets will just be dropped in those cases. I'd describe myself as pretty soft on the issue of zero UDP checksums in IPv6. After we get as many facts on the table as possible, I think we may decide that this is the best available choice for LISP, and that it shouldn't pose any serious dangers for other nodes and protocols. I think we have a bit more analysis to complete before we can be reasonably sure that this is a safe thing to do, though. There have been a lot of cases where people have implemented protocols with zero UDP checksums and have come to regret that decision later. I hope we won't be in that camp. If we do decide that this is the best thing to do, I think that we _can_ get the IETF to agree to something similar to Marshall's draft, as long as we are very specific about when the use of zero IPv6 checksums is applicable and when it is not. I am much less comfortable with sanctioning the practice of ignoring inbound non-zero UDP checksums. I understand the "buggy NAT" issue which is driving this choice, but I don't think that the ability to work behind those buggy NATs (that I _hope_ are a dying breed) is as important as leaving open the possibility that we can turn on UDP checksums in LISP later if we find that there _are_ problems in practice with using UDP zero checksums. I would also like it to be possible to implement LISP on a fairly wide set of available hardware and software, and it doesn't seem like most systems have a way to turn off checking inbound UDP checksums. Also, I'm concerned that there may be no good way to turn this off for _only_ the LISP protocol, and that we'd see boxes that don't check received UDP checksums for any of their protocols (TFTP, SNMP, etc...). I also have concerns about the impacts of corruption in the LISP header itself, and I think we need more analysis there. If we find that the LISP protocol is vulnerable to problems caused by LISP header corruption, we will need to do something to verify the integrity of the LISP header. We haven't really started this analysis, though, so I won't raise that issue unless/until we see a problem. Margaret > > > -shane > > [1] Perhaps I'm misinformed on this point and, if that's the case, I > would certainly welcome a reference to the RFC describing and/or > mandating that. I've briefly scanned RFC's 2460 & 2473 and didn't > see it addressed there. From lars.eggert@nokia.com Thu Aug 13 01:14:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02163A698D; Thu, 13 Aug 2009 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRwcD2fT+tCY; Thu, 13 Aug 2009 01:14:25 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 747943A69E0; Thu, 13 Aug 2009 01:14:23 -0700 (PDT) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7D7dudP011384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 10:39:57 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Dino Farinacci In-Reply-To: <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-8--888426508; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 10:39:56 +0300 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 13 Aug 2009 10:39:58 +0300 (EEST) Cc: "lisp@ietf.org" , "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 08:14:25 -0000 --Apple-Mail-8--888426508 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-8-11, at 19:55, Dino Farinacci wrote: > If we changed the text in the LISP draft from "MUST" to "MAY", would > we still need to write the accompanying document to RFC 2460? > > Maybe Lars can comment on this. In my opinion, any change from the MUST in RFC2460 requires updating RFC2460. Lars --Apple-Mail-8--888426508 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTMwNzM5NTdaMCMGCSqGSIb3DQEJBDEWBBTyNihbuRJUrM4P LJMrvOSDy4EIzjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEABhYeOXGoWg9nlmtQZNwvHrx8kAPd4OLFn2bxMoo10TDdWfNUCTtO Ea74u2949LiWQso+w22wb7HG1QqDmdH2ez2EeMz4qCRGIVTG54jGLKDMGEOacVn4lRlS70oREoE3 n4OOloxIwtGX1i3mPZg+oMpIWXsVAMlj+aOUDQDsDLFVGAde1JN0TStSwaWXoSekTGlmgLeDJqo7 EXQoXnQXTukIPNpQ7dEzWEkuCVbaLDASW65gDh3695lLExob3uvpn5ICXZa7HQZRzNADCWLIsLnO BIOnSkMmuMIihK6LTXVYq91/U+1YRQ2vmnUFOlV98FLSnRng+hM9b2vDrWGKEgAAAAAAAA== --Apple-Mail-8--888426508-- From lars.eggert@nokia.com Thu Aug 13 01:14:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C992A3A69A6 for ; Thu, 13 Aug 2009 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZOKUKDeDCls for ; Thu, 13 Aug 2009 01:14:25 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 65DE13A69C0 for ; Thu, 13 Aug 2009 01:14:22 -0700 (PDT) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7D8AH3S013004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 11:10:17 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <9AFEB588-BB80-4319-A05D-E57F12BA6CA3@nokia.com> From: Lars Eggert To: Sam Hartman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-10--886605656; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 11:10:17 +0300 References: X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 13 Aug 2009 11:10:18 +0300 (EEST) Cc: "lisp@ietf.org" Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 08:14:25 -0000 --Apple-Mail-10--886605656 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-8-12, at 22:51, Sam Hartman wrote: > Discussion earlier on the list focused on whether there was a need for > an explicit lisp protocol version in the header. Several participants > argued that LISP could change its port if a new version was needed. note that draft-ietf-tsvwg-iana-ports documents some of the informal rules that IANA as been using when deciding on port allocations. Section 5.1 says: A given service is expected to further demultiplex messages where possible. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same allocated port. The standing recommendation is to include a version field. Lars --Apple-Mail-10--886605656 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTMwODEwMTdaMCMGCSqGSIb3DQEJBDEWBBQzhMOGKTCdREZn P7a/wVKYeSFJPTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAKkgQ/zHZRFeM2EffEdPy/ExuMBgbMJwpMHBhCTDCjuO/bvYDR9bW xccgLkDWteFFi2iWEGvnkmu8oiIBrBhvP03ZdpQVhKBt7UsmkGbVj6Pyd+bNRJkmvUNcCMPd541J sgqGLtRCkHfpaWs5GxRxafoZxBbysP/6j4ok8ANm9wLdg2dicuFwaBuLoVoDs5tZviVPNzGWwxQY lg17gLaftoyCVsdekEZw1bk5JkM8XI7LwyxmEXxm0J7lnyHYQMshPtUkNYrEW34DqC2vZ66a3HIp mzf7ABD1SYjFawgn3UU54sf26jIq0KT628Tk2HKX9djxnFMcC1Z0oz63uJcL3AAAAAAAAA== --Apple-Mail-10--886605656-- From luigi@net.t-labs.tu-berlin.de Thu Aug 13 01:51:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5803A6A3F for ; Thu, 13 Aug 2009 01:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fXANn3tDtf2 for ; Thu, 13 Aug 2009 01:51:05 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 64F7D3A6811 for ; Thu, 13 Aug 2009 01:51:05 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id D0359701C625; Thu, 13 Aug 2009 10:49:31 +0200 (CEST) Message-Id: From: Luigi Iannone To: Margaret Wasserman In-Reply-To: <1FC87CE1-B3C5-42A6-BF13-4931ABECFCEC@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 10:49:31 +0200 References: <20090811215111.ACC066BE597@mercury.lcs.mit.edu> <74FF1CD2-C5A5-450D-B0FA-417C2AAD9054@cisco.com> <20090812162140.GA29273@1-4-5.net> <1FC87CE1-B3C5-42A6-BF13-4931ABECFCEC@sandstorm.net> X-Mailer: Apple Mail (2.936) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 08:51:06 -0000 On Aug 12, 2009, at 19:06 , Margaret Wasserman wrote: > > Thanks, Dave. A few further questions... > > On Aug 12, 2009, at 12:21 PM, David Meyer wrote: > >>>> (1) LISP does work through NATs today. We have an existence proof, >>>> many of the boxes on the LISP network >>>> are behind NATs. >>> >>> Could you explain what configuration is needed to make this work? >> >> Its actually pretty simple. You need to tell ITRs how to >> reach the ETR that is behind the NAT; as normal, the >> outside world reaches devices that are behind the NAT by >> using whatever the "outside address" is on the NAT. So >> the ETR behind the NAT needs to provide that address in >> its map-reply messages. >> >> In practice, you would configured something like >> >> ip lisp database-mapping p 1 w 100 >> >> or whatever syntax your implementation uses. Of course, >> the isn't an interface on the ETR, but >> this is easily remedied by configuring a loopback >> interface with this address. >> >> BTW, all of this can be automated in the same way the >> name to outside address binding for the NAT is automated >> with dynamic DNS. > > This makes sense, as far as it goes... > > So, if the outside address changes, how would the devices sending > the map requests know to reach the ETR at the new address? If it > used the DNS to get the address of the ETR originally, how will it > know that it should re-try DNS? How would the ETR know to start > using the new address in its mapping replies? As far as I have understood the example, this is just a change in the mapping, normal LISP mechanisms can be used for that, i.e., SMR, Nonce, versioning.... Luigi > > If the ITR inside the NAT sends a mapping request and the mapping > reply comes back directly from the remote ETR, not from the mapping > server, how does that reply reach the ITR behind the NAT? > > Margaret > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Thu Aug 13 05:19:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4843A6877 for ; Thu, 13 Aug 2009 05:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBYjj4rdZGOv for ; Thu, 13 Aug 2009 05:19:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4473E3A6778 for ; Thu, 13 Aug 2009 05:19:32 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA71F51C6; Thu, 13 Aug 2009 08:17:54 -0400 (EDT) To: Lars Eggert References: <9AFEB588-BB80-4319-A05D-E57F12BA6CA3@nokia.com> From: Sam Hartman Date: Thu, 13 Aug 2009 08:17:54 -0400 In-Reply-To: <9AFEB588-BB80-4319-A05D-E57F12BA6CA3@nokia.com> (Lars Eggert's message of "Thu\, 13 Aug 2009 11\:10\:17 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "lisp@ietf.org" Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 12:19:33 -0000 >>>>> "Lars" == Lars Eggert writes: Lars> A given service is expected to further demultiplex Lars> messages where possible. For example, applications and Lars> protocols are expected to include in-band version Lars> information, so that future versions of the application or Lars> protocol can share the same allocated port. Is this true even in cases where changes to the version are expected to be incompatible and old receivers are not expected to work with new senders? From jnc@mercury.lcs.mit.edu Thu Aug 13 06:16:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B663A684F for ; Thu, 13 Aug 2009 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9P9aI9vTtdT for ; Thu, 13 Aug 2009 06:16:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 574613A6A8F for ; Thu, 13 Aug 2009 06:16:30 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DF8066BE5A6; Thu, 13 Aug 2009 08:44:12 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090813124412.DF8066BE5A6@mercury.lcs.mit.edu> Date: Thu, 13 Aug 2009 08:44:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 13:16:34 -0000 > From: Sam Hartman > a need for an explicit lisp protocol version in the header. Several > participants argued that LISP could change its port if a new version > was needed. I think it's important to recognize that there are two different cases to consider: control traffic, and user-data traffic. For control-traffic, I pointed out in the prior discussion that we have the op-code (or whatever it's called, too lazy to go look), and we can use new op-codes to extend/modify the control-plane part of the protocol. As far as I can see, that offers equivalent flexibiilty/capabilities of a 'version' field. So we'd only have to use the new port thingy if we wanted to modify the user-data carriage protocol. Another possibility for changing the user-data protocol, _if LISP comes into wide-spread service_, is a custom protocol (i.e. directly on top of IP). Other evolution directions I have thought about for new user-data encapsulations include custom non-IPvN inter-xTR encapsulations (e.g. inside MPLS headers). (And, if it's widely used, I don't think another UDP port would be that difficult - we've been allocating UDP ports to some pretty rarely-used protocols...) My contention in the prior debate is that at this point it's not possible to pick a particular expansion direction at this time, that in making that choice we'll probably need data we don't have now, and that simply demonstrating that there are viable/plausible extension/change mechanisms available is about all we can do now. One exception to that general line of reasoning (leave the future to the future) is that I think we ought to define, at this point, a specific behaviour to respond to unrecognized op-codes, so that we can later define some sort of mechanism to negotiate control-plane upgrades. I.e. if an xTR gets a control code it doesn't recognize, it should return the entire thing, in an 'unrecognized control-type' error message, to the sending xTR. That way, if an upgraded xTR tries to talk to an un-upgraded xTR, it'll be able to tell that the other one doesn't grok the new stuff, and there can be some sort of interaction to work out what they have in common. (This is an example of my general strategy of trying to leave the right 'hooks' for the future, _iff_ LISP is successful.) Noel From jnc@mercury.lcs.mit.edu Thu Aug 13 06:25:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD03B3A6962 for ; Thu, 13 Aug 2009 06:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLCL2HQAziWR for ; Thu, 13 Aug 2009 06:25:47 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 38AE63A68B8 for ; Thu, 13 Aug 2009 06:25:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9209B6BE5A6; Thu, 13 Aug 2009 09:23:51 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090813132351.9209B6BE5A6@mercury.lcs.mit.edu> Date: Thu, 13 Aug 2009 09:23:51 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 13:25:47 -0000 > From: Lars Eggert > In my opinion, any change from the MUST in RFC2460 requires updating > RFC2460. Pfui. Let's define a new protocol, the 'LISP IPv6 User-Data Carriage Protocol'. It will be used _only_ between xTRs. To avoid allocating a new protocol number, it shares the protocol number with UDPv6, and can be distinguished from that protocol by the fact that the checksum field is _always_ zero. Should any LIUDCP packets somehow escape, and make their way to a non-xTR node, the zero checksum will cause them to be dropped - a nice side-benefit of that encoding technique. Noel From hartmans@mit.edu Thu Aug 13 06:45:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDFD3A6A63 for ; Thu, 13 Aug 2009 06:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmCQuO6WCYSY for ; Thu, 13 Aug 2009 06:45:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 1C8053A68B8 for ; Thu, 13 Aug 2009 06:45:39 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 945BB641DA; Thu, 13 Aug 2009 09:43:37 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090813124412.DF8066BE5A6@mercury.lcs.mit.edu> From: Sam Hartman Date: Thu, 13 Aug 2009 09:43:37 -0400 In-Reply-To: <20090813124412.DF8066BE5A6@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu\, 13 Aug 2009 08\:44\:12 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 13:45:39 -0000 It sounds like you would be OK doing the following: 1) Documenting behavior for unknown control message types 2) Indicating in the document that there are multiple directions we could go for data protocol extension including a new UDP port as one option. Do I have it right? From mrw@sandstorm.net Thu Aug 13 07:30:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFFE3A6AAF for ; Thu, 13 Aug 2009 07:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFDmoJhMZ0fe for ; Thu, 13 Aug 2009 07:30:20 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E2F0F3A6AA4 for ; Thu, 13 Aug 2009 07:30:19 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7DE8qNl035856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Aug 2009 10:08:53 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090813124412.DF8066BE5A6@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 10:08:52 -0400 References: <20090813124412.DF8066BE5A6@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 14:30:21 -0000 Hi Noel, On Aug 13, 2009, at 8:44 AM, Noel Chiappa wrote: > For control-traffic, I pointed out in the prior discussion that we > have the > op-code (or whatever it's called, too lazy to go look), and we can > use new > op-codes to extend/modify the control-plane part of the protocol. I think you are referring to the 4-bit "type" field at the beginning of all of the control packet headers. > As far as I > can see, that offers equivalent flexibiilty/capabilities of a > 'version' > field. So we'd only have to use the new port thingy if we wanted to > modify > the user-data carriage protocol. It is true that different LISP packet types have different formats, so the format does vary based on the value of the type field. The field is 4-bits long (16 values), and 8 of the 16 values have already been allocated, but we could easily make more space by using type 15 (all ones) as an escape to additional types. So, I think this is a reasonable choice. > > One exception to that general line of reasoning (leave the future to > the > future) is that I think we ought to define, at this point, a specific > behaviour to respond to unrecognized op-codes, so that we can later > define > some sort of mechanism to negotiate control-plane upgrades. Yes, this would be a good idea. We might also want to explicitly reserve 15 as an extension mechanism, so that when we send the registry for these types off to IANA (with whatever IANA considerations we devise) there is no chance that the last value will be allocated without providing for an extension. > > I.e. if an xTR gets a control code it doesn't recognize, it should > return the > entire thing, in an 'unrecognized control-type' error message, to > the sending > xTR. That way, if an upgraded xTR tries to talk to an un-upgraded > xTR, it'll > be able to tell that the other one doesn't grok the new stuff, and > there can > be some sort of interaction to work out what they have in common. > > (This is an example of my general strategy of trying to leave the > right > 'hooks' for the future, _iff_ LISP is successful.) This mechanism makes sense to me. Perhaps one of the authors should open an issue for this, so that we make sure that the text gets into the -04 version? Now for LISP data packets: > Another possibility for changing the user-data protocol, _if LISP > comes into > wide-spread service_, is a custom protocol (i.e. directly on top of > IP). > Other evolution directions I have thought about for new user-data > encapsulations include custom non-IPvN inter-xTR encapsulations > (e.g. inside > MPLS headers). > > (And, if it's widely used, I don't think another UDP port would be > that > difficult - we've been allocating UDP ports to some pretty rarely-used > protocols...) > > My contention in the prior debate is that at this point it's not > possible to > pick a particular expansion direction at this time, that in making > that > choice we'll probably need data we don't have now, and that simply > demonstrating that there are viable/plausible extension/change > mechanisms > available is about all we can do now. While its true that we could extend and modify LISP in a number of ways including defining additional encapsulations, I actually consider this to be an argument _for_ LISP data headers having a version field, rather than relying on UDP port numbers. Because we might not always have UDP available to tell us what version of the LISP header this is... Or would you expect to obtain multiple IP protocol or next- header values to denote different LISP versions directly over IP? And different MPLS protocol types to denote different versions of LISP over MPLS? etc? If a LISP data packet of the current version is transmitted using MPLS over carrier pigeon, it should still be recognizable as the same version of the LISP protocol. However, if we need to change the LISP data header in the future, it would be good if receiving nodes could unambiguously recognize that they are dealing with a new LISP data header version, without relying on the lower layer to demultiplex. Relying on the lower layer to demultiplex between different LISP versions makes it impossible for an ITR to distinguish between a destination node that doesn't implement LISP and an ETR that implements a different version of LISP. If we include a version field in the LISP data header, we could also define an error message (the same in all versions) that is sent by an ETR when it receives a LISP data packet that isn't the right version. If we just use UDP ports to demultiplex, though, the packet will be dropped with a much less specific ICMP "port unreachable" error -- the same error you would get if the destination did not implement LISP at all. Margaret From jnc@mercury.lcs.mit.edu Thu Aug 13 07:40:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10D83A69EB for ; Thu, 13 Aug 2009 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cE+zx8zWepE for ; Thu, 13 Aug 2009 07:40:45 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D36F53A6942 for ; Thu, 13 Aug 2009 07:40:44 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3BBA26BE556; Thu, 13 Aug 2009 10:40:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> Date: Thu, 13 Aug 2009 10:40:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 14:40:45 -0000 > From: Margaret Wasserman > The field is 4-bits long (16 values), and 8 of the 16 values have > already been allocated, but we could easily make more space by using > type 15 (all ones) as an escape to additional types. Ecchh. A little tacky, but I guess that would work. If we have to change the header format at any point (as we are thinking of doing for the user-data encapsulation, to add nonce echoing), I'd prefer to add a few more bits to that field, but that's a wish-list item. Your suggestion is certainly a perfectly functional alternative, if the space runs out. > We might also want to explicitly reserve 15 as an extension mechanism, > so that when we send the registry for these types off to IANA .. there > is no chance that the last value will be allocated without providing > for an extension. Good idea. > Perhaps one of the authors should open an issue for this, so that we > make sure that the text gets into the -04 version? Do we need a separate issue? To me, it's all part of 'protocol extensibility' (although I guess, now that I write that phrase, that it covers a lot of ground... :-). (It's not like I wildly object, just trying to minimize the amount of scribal work.. :-) > we might not always have UDP available to tell us what version of the > LISP header this is... Or would you expect to obtain multiple IP > protocol or next- header values to denote different LISP versions > directly over IP? And different MPLS protocol types to denote different > versions of LISP over MPLS? If we had LISP running directly on IP or MPLS, I would definitely want to see a version number field in that header. (I would not think we could use the existing LISP user-data headers, unmodified, in either case anyway, so not having one now in the UDP user-data header is not an issue to me.) > Relying on the lower layer to demultiplex between different LISP > versions makes it impossible for an ITR to distinguish between a > destination node that doesn't implement LISP and an ETR that implements > a different version of LISP. Well, remember, this is only user-data traffic we're considering. There will be control traffic between the two xTRs, which will allow them to figure out which version of LISP they are running, etc. Although maybe we should make sure the Map-Reply message can indicate something about the version status of the xTR in question? I had sort of assumed that the ability to reply with multiple RLOCs, with a different AFI for each, would be enough, but maybe not? We could use different AFI's as a proxy (e.g. have 4 AFI's assigned for IPv4, to indicate different IPv4 encapsulations...) Not sure if that's feasible - we should be able to have LISP-specific AFI space values, I would think? > If we include a version field in the LISP data header, we could also > define an error message .. that is sent by an ETR when it receives a > LISP data packet that isn't the right version. If we just use UDP ports > to demultiplex, though, the packet will be dropped with a much less > specific ICMP "port unreachable" error -- the same error you would get > if the destination did not implement LISP at all. Again, we have a separate control-plane channel. So an xTR can easily check to see if another node is running LISP by sending a LISP control-plane message to it. If a particular user-data UDP encapsulation _then_ produces an ICMP error, that pretty much says 'this encapsulation not supported'. Or we could define a control-plane interaction to ask/reply what user-data encapsulations are supported. And there's always the Map-Reply thing (above), too. Noel From jnc@mercury.lcs.mit.edu Thu Aug 13 07:43:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D003A6B88 for ; Thu, 13 Aug 2009 07:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf2ZkyvIURSa for ; Thu, 13 Aug 2009 07:43:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id AFA683A6B71 for ; Thu, 13 Aug 2009 07:43:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4641B6BE556; Thu, 13 Aug 2009 10:42:52 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090813144252.4641B6BE556@mercury.lcs.mit.edu> Date: Thu, 13 Aug 2009 10:42:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 14:43:29 -0000 > From: Sam Hartman > It sounds like you would be OK doing the following: > ... > Do I have it right? Yes, I'm OK with that - not sure about the rest of the WG! :-) (And we should add the control-plane stuff to the writeup, too.) Noel From mrw@sandstorm.net Thu Aug 13 07:52:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A627C3A6B88 for ; Thu, 13 Aug 2009 07:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwFP8tlwgQBE for ; Thu, 13 Aug 2009 07:52:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id C5EEC3A6B71 for ; Thu, 13 Aug 2009 07:52:04 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7DEols4037771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Aug 2009 10:50:47 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 10:50:47 -0400 References: <20090813144010.3BBA26BE556@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 14:52:05 -0000 On Aug 13, 2009, at 10:40 AM, Noel Chiappa wrote: > > Do we need a separate issue? To me, it's all part of 'protocol > extensibility' > (although I guess, now that I write that phrase, that it covers a > lot of > ground... :-). (It's not like I wildly object, just trying to > minimize the > amount of scribal work.. :-) Sorry, I didn't realize (or forgot) that there was already an issue open for this. > Again, we have a separate control-plane channel. So an xTR can > easily check > to see if another node is running LISP by sending a LISP control-plane > message to it. If a particular user-data UDP encapsulation _then_ > produces an > ICMP error, that pretty much says 'this encapsulation not supported'. > > Or we could define a control-plane interaction to ask/reply what > user-data > encapsulations are supported. And there's always the Map-Reply thing > (above), > too. These are good points. A control-plane mechanism to determine what version(s) of LISP an xTR supports (whether it is part of the mapping reply or a separate control message) would address most of my reasons for wanting a LISP data header version. If necessary, the control plane could even be used to negotiate what version to use. This negotiation could be very simple, like we use the highest version we both support, but it would make it clear what version of LISP data packets the ETR should expect to receive from a specific ITR. Margaret From dino@cisco.com Thu Aug 13 08:33:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE7A3A6B67; Thu, 13 Aug 2009 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWIYO0YvbwWo; Thu, 13 Aug 2009 08:33:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E5E5E3A6A9C; Thu, 13 Aug 2009 08:33:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO/Mg0qrR7MV/2dsb2JhbAC7aYgrkQAFhBk X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="366735264" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2009 15:24:27 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7DFOR7G004768; Thu, 13 Aug 2009 08:24:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7DFORcZ019122; Thu, 13 Aug 2009 15:24:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 08:24:27 -0700 Received: from [192.168.1.3] ([10.21.71.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 08:24:27 -0700 Message-Id: <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> From: Dino Farinacci To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 08:24:27 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 13 Aug 2009 15:24:27.0194 (UTC) FILETIME=[253561A0:01CA1C2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=453; t=1250177067; x=1251041067; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=ZJL5R0SximRSJLwLo8LizC4+vk3LEiWOdgLMv0dts7Q=; b=iP1464E6HM6ZPfWFbYlu/giKaNW/JdcoSCduHQTYWaWADtofxL25PQ4ysP h+XBfekK4DCB6bmZkrjam+ip5pVUbC7BGX9TbWYQohb6/C7U+biGDAprzDUC C9QqfdAzy0to5vfzRxi/rlD06gWfgTSg/ziDeBjdO8RL5w0TY6IZ8=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "lisp@ietf.org" , "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 15:33:10 -0000 > On 2009-8-11, at 19:55, Dino Farinacci wrote: >> If we changed the text in the LISP draft from "MUST" to "MAY", would >> we still need to write the accompanying document to RFC 2460? >> >> Maybe Lars can comment on this. > > In my opinion, any change from the MUST in RFC2460 requires updating > RFC2460. > > Lars From my text I wrote above, if we changed from MUST to MAY *in the LISP draft*, do we have to update RFC2460? Dino From fred@cisco.com Thu Aug 13 08:36:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B3D3A6968; Thu, 13 Aug 2009 08:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.813 X-Spam-Level: X-Spam-Status: No, score=-105.813 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2+SRLN0L2WN; Thu, 13 Aug 2009 08:36:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 34B9D3A6945; Thu, 13 Aug 2009 08:36:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="40831252" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2009 15:33:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7DFXQkO023446; Thu, 13 Aug 2009 08:33:26 -0700 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7DFXQPo016503; Thu, 13 Aug 2009 15:33:26 GMT Message-Id: <5B6CD463-F1ED-4D17-A023-126F3DBB9374@cisco.com> From: Fred Baker To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 08:33:25 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1515; t=1250177606; x=1251041606; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=kmGb/ffGClCSLg9wi4SQZN19MRz3kOrempPdAFqNQrU=; b=LcQWqTGja61Gbdw4wtH3uxgS7phLpBo96/e9aJM0qGRomCefqdr/6eSoNs e1pd/5/ZYIivYH6030lfQWmI+yoHvYSn/leilWK88h3/6irPrFNRWrJSYY2B U4zKdh6Jnd; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Margaret Wasserman , ipv6@ietf.org, lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 15:36:45 -0000 that of course begs the question of what a system that forwards =20 traffic from an interface to a tunnel-like encapsulation is; I tend to =20= think that it did something with a packet not directed to it and is =20 therefore a router, but your text below would suggest that it is a host. On Aug 13, 2009, at 8:13 AM, R=E9mi Despr=E9s wrote: > Fred, > > Your proposal seems to me in the best direction. > > For a full agreement, it would however be appropriate IMHO to be =20 > more precise: > - A v4 to v6 translator MAY (for efficiency) not recalculate =20 > checksums of UDP datagrams received with zero checksums. > - If it doesn't recalculate them, it SHOULD forward datagrams with =20 > their zero checksum > - An IPv4 host MAY transmit zero-checksum UDP datagrams and MUST =20 > accept them > - An IPv6 host MUST transmit UDP datagrams with non-zero checksums =20 > and MAY accept them with zero checksums. > > Would this fit with what you wish? > > Regards, > RD > > > > Le 11 ao=FBt 09 =E0 19:13, Fred Baker a =E9crit : >> I would expect a NAT that saw a zero value to not recalculate the =20 >> checksum. >> >> I agree that the unilateral change to the UDP protocol built into =20 >> RFC 2460 was a bad idea; if you want to change UDP, change UDP. =20 >> That is probably water under the bridge now. >> >> I think that I would word this as: >> >> UDP Checksum: this field MAY be transmitted as zero, and the =20 >> receiver MAY ignore the checksum on receipt. From fred@cisco.com Thu Aug 13 08:39:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AEA3A6968; Thu, 13 Aug 2009 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijwu3CuAYSBW; Thu, 13 Aug 2009 08:39:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 501623A6A57; Thu, 13 Aug 2009 08:38:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="183258298" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2009 15:30:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7DFUxw0032076; Thu, 13 Aug 2009 08:30:59 -0700 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7DFUxVO012659; Thu, 13 Aug 2009 15:30:59 GMT Message-Id: <621F6751-6352-4C1F-BDEA-5F30FB7B8A54@cisco.com> From: Fred Baker To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 08:30:59 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=349; t=1250177459; x=1251041459; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=+bb7meVE1IFL7M8vC7r/UQ67gGNU2hXH9bjkzhNhNDA=; b=gW6YVSobN3asblxpbxZlAZqiG8ye44yVrBG1I2gmI6tV2NB3tjuJs8km12 gRHNakvEZXcp6Bk6bxr9g/Sm0oxR7zwQ1NoUH5P/D8BUSzQmb+kwKlGhrJqw auzwDtepQv; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Margaret Wasserman , "ipv6@ietf.org" , "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 15:39:40 -0000 On Aug 13, 2009, at 12:39 AM, Lars Eggert wrote: > In my opinion, any change from the MUST in RFC2460 requires updating > RFC2460. No problem. Rip out of 2460-bis anything that is not related to IPv6, and say that it MUST be implemented as a change to RFC 768 or whatever else. That's what should have happened in the first place. From luigi@net.t-labs.tu-berlin.de Thu Aug 13 08:45:02 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1183A68A6; Thu, 13 Aug 2009 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vALxR8PWMArm; Thu, 13 Aug 2009 08:45:02 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id D14543A6882; Thu, 13 Aug 2009 08:45:01 -0700 (PDT) Received: from dyn106.net.t-labs.tu-berlin.de (dyn106.net.t-labs.tu-berlin.de [130.149.220.106]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 145C0700DBAC; Thu, 13 Aug 2009 17:41:51 +0200 (CEST) Message-Id: <61B4EB06-2B89-4AA9-B0F2-B417F7173E77@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Francis Dupont In-Reply-To: <200908131456.n7DEuCJg052586@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 17:41:50 +0200 References: <200908131456.n7DEuCJg052586@givry.fdupont.fr> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 15:45:02 -0000 On Aug 13, 2009, at 16:56 , Francis Dupont wrote: > In your previous mail you wrote: > > If you want LISP on a desktop OS you need to update that OS, hence > at > the same time you can patch it to handle the 0 UDP checksum > consequently. > > => I disagree, it is easy to implement LISP in user mode (using > the tun/tap interface/device driver for instance). > It is also easy to do it with pcap and then you do what you want with the packet. Luigi > Regards > > Francis.Dupont@fdupont.fr From lars.eggert@nokia.com Thu Aug 13 09:46:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4475D3A6B8A; Thu, 13 Aug 2009 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD4NeVxUWRxm; Thu, 13 Aug 2009 09:46:40 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id E3E5A3A68CF; Thu, 13 Aug 2009 09:46:39 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7DGLZUr039769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 19:21:35 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Dino Farinacci In-Reply-To: <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-26--857127856; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 19:21:35 +0300 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 13 Aug 2009 19:21:35 +0300 (EEST) Cc: "lisp@ietf.org" , "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 16:46:41 -0000 --Apple-Mail-26--857127856 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, yes, because RFC2460 says "MUST use always" and the intent here is to loosen that restriction for LISP and AMT. (And I'm sure Noel will again call this "red-tape legalese", but the fact is that this change revises the standing IETF consensus, and there's a process for that.) Lars On 2009-8-13, at 18:24, Dino Farinacci wrote: >> On 2009-8-11, at 19:55, Dino Farinacci wrote: >>> If we changed the text in the LISP draft from "MUST" to "MAY", would >>> we still need to write the accompanying document to RFC 2460? >>> >>> Maybe Lars can comment on this. >> >> In my opinion, any change from the MUST in RFC2460 requires updating >> RFC2460. >> >> Lars > > From my text I wrote above, if we changed from MUST to MAY *in the > LISP draft*, do we have to update RFC2460? > > Dino > --Apple-Mail-26--857127856 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTMxNjIxMzVaMCMGCSqGSIb3DQEJBDEWBBQVFRFJdHehtGHq UFqTe65eiCzOHTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEABYrP6jvLyF0uiNzG2sF2GWyJx6Lse+LJ+GozuD2V4fpGNWQWIQIv L8Rniqj+S5HRC5kwYU1RpZOguTp2YOTVPNkOc5EmP8iWMooSscLQlQextqHTzDy9JrJ1ZEpSmOHE 3pzHy/hNiVnkSj+FTyaI7njls8ZfTbwOn73+XXuwp2ivauyeypOHLI25otC1XbQYL05WMNU91VNT 3LLCuhNGCu5d6ZQYKR9yk+QII8Y9rdBiI/5h7ewgW1zh83nbv+FRVBHdrwcvEyea12UKlNXeoyEc ysIPnyjSeJMK6tMpsf0/hjxs2+Mng/LJBkl2mo6PB312CVA78a4KWJE+o5+qqQAAAAAAAA== --Apple-Mail-26--857127856-- From hartmans@mit.edu Thu Aug 13 10:50:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3067D3A6CCA; Thu, 13 Aug 2009 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjF0HZqelQBE; Thu, 13 Aug 2009 10:50:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6EDDA3A6B9A; Thu, 13 Aug 2009 10:50:25 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15536641DA; Thu, 13 Aug 2009 13:50:21 -0400 (EDT) To: Lars Eggert References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> From: Sam Hartman Date: Thu, 13 Aug 2009 13:50:21 -0400 In-Reply-To: (Lars Eggert's message of "Thu\, 13 Aug 2009 19\:21\:35 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman , "ipv6@ietf.org" , "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 17:50:26 -0000 >>>>> "Lars" == Lars Eggert writes: Lars> Hi, yes, because RFC2460 says "MUST use always" and the Lars> intent here is to loosen that restriction for LISP and AMT. Lars> (And I'm sure Noel will again call this "red-tape legalese", Lars> but the fact is that this change revises the standing IETF Lars> consensus, and there's a process for that.) Something that apparently isn't obvious to some WG participants who have contacted me off-list is that it is quite possible to change an IETF consensus. When Margaret, Lars and I talk about doing things like updating RFC 2460, we're not talking about what we think should be a obstruction once we've done the work to decide what the right technical direction is. We've all been on the IESG and are used to these sorts of updates as a routine matter of IETF business. In the simplest case, you're talking about writing a potentially short draft that updates the spec in question. You then find the appropriate AD or working group to sponsor the draft and go through the normal process. Yes, you do actually have to build consensus. For some updates, that's easy, for others it is very difficult. That's how we all convince each other that we actually have thought things through and come to the right decision. From Fred.L.Templin@boeing.com Thu Aug 13 11:18:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601573A67AA; Thu, 13 Aug 2009 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHzdkVjtNmGT; Thu, 13 Aug 2009 11:18:47 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 831C53A6C2F; Thu, 13 Aug 2009 11:18:47 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7DIIOC9024842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 11:18:24 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7DIIN2R003478; Thu, 13 Aug 2009 11:18:23 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7DIIMbL003418; Thu, 13 Aug 2009 11:18:23 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 11:18:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 11:18:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106455A2C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <262D32F1-B0DE-45F8-864C-D1265AB2D99D@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Judging Consensus on the UDP Checksum Issue Thread-Index: AcocOnJScrAsfl1WRvy0Yf7FqvYBaAAB0tOQ References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu><928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net><32AADADD-6A45-4565-91D5-F095AE713215@cisco.com><5B6CD463-F1ED-4D17-A023-126F3DBB9374@cisco.com> <262D32F1-B0DE-45F8-864C-D1265AB2D99D@free.fr> From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Fred Baker" X-OriginalArrivalTime: 13 Aug 2009 18:18:18.0397 (UTC) FILETIME=[6EB0A4D0:01CA1C42] Cc: Noel Chiappa , ipv6@ietf.org, lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 18:18:48 -0000 Any node (host or router) that configures a tunnel endpoint is the source of packets that it originates from its tunnel interface. As such, it may perform host-based fragmentation, receive ICMP errors, etc. in a way that is typically associated with a host. Whether you view it as a router with an embedded host function or a host with an embedded gateway function is dependent on specific use cases and/or one's point of view. Fred fred.l.templin@boeing.com > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Thursday, August 13, 2009 10:20 AM > To: Fred Baker > Cc: Margaret Wasserman; ipv6@ietf.org; lisp@ietf.org; Dino Farinacci; = Noel Chiappa > Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue >=20 >=20 > Le 13 ao=FBt 09 =E0 17:33, Fred Baker a =E9crit : >=20 > > that of course begs the question of what a system that forwards > > traffic from an interface to a tunnel-like encapsulation is; I tend > > to think that it did something with a packet not directed to it and > > is therefore a router, >=20 > The distinction between a router and a host is not always clear. > Basically, a node acts "as a host" on packets > - it receives with a destination address that is one of its own > addresses > - it sends with a source address that is one of its own addresses. > It acts "as a router" on other packets >=20 > Thus, an encapsulating function: > - acts "as a host" on the link where outer headers are routed. > - acts as link layer interface module to a "router function" on its > side where packets have only the inner headers. >=20 > Would this clarify (or make things worth)? >=20 > Regards, > RD >=20 >=20 >=20 >=20 > > but your text below would suggest that it is a host. > > > > On Aug 13, 2009, at 8:13 AM, R=E9mi Despr=E9s wrote: > > > >> Fred, > >> > >> Your proposal seems to me in the best direction. > >> > >> For a full agreement, it would however be appropriate IMHO to be > >> more precise: > >> - A v4 to v6 translator MAY (for efficiency) not recalculate > >> checksums of UDP datagrams received with zero checksums. > >> - If it doesn't recalculate them, it SHOULD forward datagrams with > >> their zero checksum > >> - An IPv4 host MAY transmit zero-checksum UDP datagrams and MUST > >> accept them > >> - An IPv6 host MUST transmit UDP datagrams with non-zero checksums > >> and MAY accept them with zero checksums. > >> > >> Would this fit with what you wish? > >> > >> Regards, > >> RD > >> > >> > >> > >> Le 11 ao=FBt 09 =E0 19:13, Fred Baker a =E9crit : > >>> I would expect a NAT that saw a zero value to not recalculate the > >>> checksum. > >>> > >>> I agree that the unilateral change to the UDP protocol built into > >>> RFC 2460 was a bad idea; if you want to change UDP, change UDP. > >>> That is probably water under the bridge now. > >>> > >>> I think that I would word this as: > >>> > >>> UDP Checksum: this field MAY be transmitted as zero, and the > >>> receiver MAY ignore the checksum on receipt. > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dino@cisco.com Thu Aug 13 12:47:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3471828C1D1; Thu, 13 Aug 2009 12:47:01 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0DX5ewKAvhB; Thu, 13 Aug 2009 12:47:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 47D7D3A67FF; Thu, 13 Aug 2009 12:47:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAsLhEqrR7O6/2dsb2JhbAC7K4grkRoFhBk X-IronPort-AV: E=Sophos;i="4.43,375,1246838400"; d="scan'208";a="366902668" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2009 19:46:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7DJkv3u002987; Thu, 13 Aug 2009 12:46:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7DJkv1R008119; Thu, 13 Aug 2009 19:46:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:46:57 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:46:57 -0700 Message-Id: <5AFA24E6-8971-4976-AA24-B1C48AC6470C@cisco.com> From: Dino Farinacci To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 12:46:57 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 13 Aug 2009 19:46:57.0518 (UTC) FILETIME=[D12218E0:01CA1C4E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=962; t=1250192817; x=1251056817; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=QnCWhm0jPdMHzzbJn0Op43VqAi0M2UVC8yQFTNrf1lo=; b=Y2HkcIYKz5UO6zLYNnQUAVmZf5l42ePiKbqgcaJngUS7hXbPiLjch4jGfA 1kl7xOzeMOv3gf4CjzM/yzGz8aRWLOAMsWwLg4DjsvQbEDhbklj9ri7x/09R 94QbL9L8E2; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "lisp@ietf.org" , "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 19:47:01 -0000 Ack. Thanks for the answer. Dino On Aug 13, 2009, at 9:21 AM, Lars Eggert wrote: > Hi, > > yes, because RFC2460 says "MUST use always" and the intent here is > to loosen that restriction for LISP and AMT. > > (And I'm sure Noel will again call this "red-tape legalese", but the > fact is that this change revises the standing IETF consensus, and > there's a process for that.) > > Lars > > On 2009-8-13, at 18:24, Dino Farinacci wrote: > >>> On 2009-8-11, at 19:55, Dino Farinacci wrote: >>>> If we changed the text in the LISP draft from "MUST" to "MAY", >>>> would >>>> we still need to write the accompanying document to RFC 2460? >>>> >>>> Maybe Lars can comment on this. >>> >>> In my opinion, any change from the MUST in RFC2460 requires updating >>> RFC2460. >>> >>> Lars >> >> From my text I wrote above, if we changed from MUST to MAY *in the >> LISP draft*, do we have to update RFC2460? >> >> Dino >> > From tme@americafree.tv Thu Aug 13 18:20:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CDA3A6A6C; Thu, 13 Aug 2009 18:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxoYfYGyLqQR; Thu, 13 Aug 2009 18:20:24 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 7067A3A683A; Thu, 13 Aug 2009 18:20:24 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 49C5E47A0F11; Thu, 13 Aug 2009 21:20:27 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Brian Haberman In-Reply-To: <4A847D96.1070606@innovationslab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 21:20:25 -0400 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> <4A847D96.1070606@innovationslab.net> X-Mailer: Apple Mail (2.936) Cc: "ipv6@ietf.org" , "lisp@ietf.org" , Margaret Wasserman , Noel Chiappa Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 01:20:25 -0000 On Aug 13, 2009, at 4:54 PM, Brian Haberman wrote: > Sam Hartman wrote: >>>>>>> "Lars" == Lars Eggert writes: >> Lars> Hi, yes, because RFC2460 says "MUST use always" and the >> Lars> intent here is to loosen that restriction for LISP and AMT. >> Lars> (And I'm sure Noel will again call this "red-tape legalese", >> Lars> but the fact is that this change revises the standing IETF >> Lars> consensus, and there's a process for that.) >> Something that apparently isn't obvious to some WG participants who >> have contacted me off-list is that it is quite possible to change an >> IETF consensus. When Margaret, Lars and I talk about doing things >> like updating RFC 2460, we're not talking about what we think should >> be a obstruction once we've done the work to decide what the right >> technical direction is. >> We've all been on the IESG and are used to these sorts of updates >> as a >> routine matter of IETF business. >> In the simplest case, you're talking about writing a potentially >> short >> draft that updates the spec in question. You then find the >> appropriate AD or working group to sponsor the draft and go through >> the normal process. >> Yes, you do actually have to build consensus. For some updates, >> that's easy, for others it is very difficult. That's how we all >> convince each other that we actually have thought things through and >> come to the right decision. > > Finally a point that is appropriate to the 6man mailing list... > There are two proposals on the table to do just that (modify the > handling of UDP as defined in 2460). The discussion should be on > the tradeoffs of those two proposals. > > http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 proposes > allowing UDP to have a zero checksum in certain conditions (i.e., > outer checksum is zero as long as there is an encapsulated UDP > checksum that is valid). > We envision draft-eubanks-chimento-6man-00, should it go through, as explicitly updating RFC2460 and the next version will reflect this. Regards Marshall > http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01 > proposes a "checksum per flow" approach that is applicable for UDP > tunneled inside of UDP. > > The chairs of 6MAN would like to here feedback on these drafts as > they apply to the problem spaces raised (AMT, v4/v6 translators, and > LISP). > > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From dino@cisco.com Thu Aug 13 20:44:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E127D3A684C; Thu, 13 Aug 2009 20:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZKgjrbt0TsJ; Thu, 13 Aug 2009 20:44:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 284993A6881; Thu, 13 Aug 2009 20:44:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANd6hEqrR7O6/2dsb2JhbAC6NIgrkSEFhBk X-IronPort-AV: E=Sophos;i="4.43,378,1246838400"; d="scan'208";a="227835303" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2009 03:44:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7E3iYxm028772; Thu, 13 Aug 2009 20:44:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7E3iYEK012362; Fri, 14 Aug 2009 03:44:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 20:44:34 -0700 Received: from [192.168.1.4] ([10.21.72.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 20:44:33 -0700 Message-Id: <63C59D04-8A9B-4F96-A69B-FE67BE0F08E2@cisco.com> From: Dino Farinacci To: Brian Haberman In-Reply-To: <4A847D96.1070606@innovationslab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 13 Aug 2009 20:44:33 -0700 References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> <4A847D96.1070606@innovationslab.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 14 Aug 2009 03:44:33.0765 (UTC) FILETIME=[89966150:01CA1C91] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=653; t=1250221474; x=1251085474; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Judging=20Consensus=20on=20the =20UDP=20Checksum=20Issue |Sender:=20; bh=74HMcU8Ry6L/MwIz3YMh7if794kTrFLGdsR57IKGHu4=; b=HTyA4qThrNmXEjMWPEYcCLpMMDRuxcg1/EFbJPVbPUEKS8lck3A66poUkA taSwtl8xhd4poMTwg/Gk7HtZVComMPOH/7mFeB9f15vIFuc1OEzoPUDAw4KW aLF/HSQTNB; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman , "lisp@ietf.org" Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 03:44:32 -0000 > The chairs of 6MAN would like to here feedback on these drafts as > they apply to the problem spaces raised (AMT, v4/v6 translators, and > LISP). From my perspective, AMT and LISP both have the same requirements in terms of performance and having encapsulation work well over LAGs. It turns out that there is even a greater performance issue with AMT because as you replicate a multicast packet to each gateway tunnel, the outer IP addresses are different for each tunnel and therefore require a different pseudo-header to be built for each UDP replicated encapsulation. So I am in support of Marshall's draft. Dino From brian@innovationslab.net Thu Aug 13 15:13:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05C028C178; Thu, 13 Aug 2009 15:13:22 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDRBCNDPMzAK; Thu, 13 Aug 2009 15:13:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 0F8463A67B8; Thu, 13 Aug 2009 15:13:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3B1AA8820F; Thu, 13 Aug 2009 13:54:55 -0700 (PDT) Received: from Clemson-2.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CA0D5130002; Thu, 13 Aug 2009 13:54:52 -0700 (PDT) Message-ID: <4A847D96.1070606@innovationslab.net> Date: Thu, 13 Aug 2009 16:54:46 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Sam Hartman References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Aug 2009 09:00:10 -0700 Cc: "ipv6@ietf.org" , Noel Chiappa , Margaret Wasserman , "lisp@ietf.org" Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Aug 2009 22:13:22 -0000 Sam Hartman wrote: >>>>>> "Lars" == Lars Eggert writes: > > Lars> Hi, yes, because RFC2460 says "MUST use always" and the > Lars> intent here is to loosen that restriction for LISP and AMT. > > Lars> (And I'm sure Noel will again call this "red-tape legalese", > Lars> but the fact is that this change revises the standing IETF > Lars> consensus, and there's a process for that.) > > Something that apparently isn't obvious to some WG participants who > have contacted me off-list is that it is quite possible to change an > IETF consensus. When Margaret, Lars and I talk about doing things > like updating RFC 2460, we're not talking about what we think should > be a obstruction once we've done the work to decide what the right > technical direction is. > > We've all been on the IESG and are used to these sorts of updates as a > routine matter of IETF business. > > In the simplest case, you're talking about writing a potentially short > draft that updates the spec in question. You then find the > appropriate AD or working group to sponsor the draft and go through > the normal process. > > Yes, you do actually have to build consensus. For some updates, > that's easy, for others it is very difficult. That's how we all > convince each other that we actually have thought things through and > come to the right decision. Finally a point that is appropriate to the 6man mailing list... There are two proposals on the table to do just that (modify the handling of UDP as defined in 2460). The discussion should be on the tradeoffs of those two proposals. http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 proposes allowing UDP to have a zero checksum in certain conditions (i.e., outer checksum is zero as long as there is an encapsulated UDP checksum that is valid). http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01 proposes a "checksum per flow" approach that is applicable for UDP tunneled inside of UDP. The chairs of 6MAN would like to here feedback on these drafts as they apply to the problem spaces raised (AMT, v4/v6 translators, and LISP). Regards, Brian From hartmans@mit.edu Fri Aug 14 11:11:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D7D3A68B0 for ; Fri, 14 Aug 2009 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LTkqF54EcgY for ; Fri, 14 Aug 2009 11:11:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4E3743A6817 for ; Fri, 14 Aug 2009 11:11:57 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B596D641DA; Fri, 14 Aug 2009 14:11:53 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 14 Aug 2009 14:11:53 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Status on UDP checksum issue X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Aug 2009 18:11:58 -0000 I wanted to let the WG know where I think we are. I'm told by Darrel that Margaret's issues will be opened early next week. That's certainly a long delay between issues being sent to the list and entered into the tracker, and under normal circumstances if I thought things were going to drag out like that I might well just enter the issues myself. However, I think getting more people used to dealing with the tracker is good and deferring the continuation of the discussion until over the weekend also sounds reasonable. Darrel and I had a nice conversation about how we can work to educate each other. I expect he'll be telling us more about that in the near future. I've had several conversations about how to make the WG work more smoothly and am open to talking to anyone who has ideas about that. I believe that Margaret is still investigating the impact of permitting 0 UDP checksums for IPV6. This analysis includes: * LISP packets sent to the wrong destination * LISP packets sent to some non-LISP endpoint * LISP packets corrupted in transit I have not talked to Marshall but I assume he's been following this discussion and will reflect a number of issues in his draft. Anyone who wants to flesh out an alternative for meeting some or all of the requirements stated in this discussion such as something based on using multiple IPV6 source addresses should do so. If you want such an alternative to be seriously considered you may be asked to prepare a draft under reasonably tight time pressure, so you should not be surprised by that. Requirements participants have stated include: * Works with LAGs/ECMP * Implementable in router hardware * Implementable on stock TCP/IP stacks * Implementable using server/desktop NICs with checksum offload * Can be easily deployed * Works through firewalls and NATs We have not yet judged formally whether some or all of these requirements are important to the WG as a whole. We may b e able to move forward without that although refocusing on the requirements is certainly a tool that is available to us. A while ago, I published a sort of proto consensus call. It seems unlikely at this point that any eventual consensus call will be of the form I published previously, although input we've received so far will certainly be considered. From lear@cisco.com Mon Aug 17 09:58:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1FA3A6D15 for ; Mon, 17 Aug 2009 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.985 X-Spam-Level: X-Spam-Status: No, score=-9.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz80k6QPzpD6 for ; Mon, 17 Aug 2009 09:58:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5972B3A6D5C for ; Mon, 17 Aug 2009 09:58:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAAPcoiUqQ/uCKe2dsb2JhbACBUpkvAQEWJAaje4gtjyAFhBmCLg X-IronPort-AV: E=Sophos;i="4.43,397,1246838400"; d="scan'208";a="47277849" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2009 16:58:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7HGwhED011925; Mon, 17 Aug 2009 18:58:43 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp1992.cisco.com [10.61.71.200]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7HGwgCJ028183; Mon, 17 Aug 2009 16:58:42 GMT Message-ID: <4A898C42.80406@cisco.com> Date: Mon, 17 Aug 2009 18:58:42 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "Joel M. Halpern" References: <3575B6BB-E56E-4E93-A17C-9E25A9808BD8@sandstorm.net> <4A8328E1.9@joelhalpern.com> In-Reply-To: <4A8328E1.9@joelhalpern.com> X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2968; t=1250528323; x=1251392323; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20[#5]=20LISP=20protocol=20versi on |Sender:=20; bh=0ZeLGI7ci3ovobj/fMhKnlBf9j7ptjxYXQd3g7gtr2g=; b=gRxczgGCNdGrpT0GSPoR7ujLg2Gk4uW0RIqMwU/tSAg574FuVqIpfRAP0w GbAgC8LoDJWp4hEeNbUBy54N77n/UPFwMy14fqsUNZW3/8iO2Ff6AE9eSWgA q9MwQ0JxVZ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] [#5] LISP protocol version X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2009 16:58:40 -0000 Joel, As one of the IANA expert reviewers for port assignments, in general we'll be pretty harsh with application-level protocols that apply for a port without a version #. In particular, we won't approve updates to that protocol, for sure. This case is different. LISP is meant to sit under EVERYTHING, and the protocol version number, even though only a byte is a byte EVERYWHERE that could get even get wrapped around a few times. As such, were the review to fall to me, I would recommend approval without a version #. Eliot On 8/12/09 10:41 PM, Joel M. Halpern wrote: > I am actually inclined towards the port number, because I think if we > actually need a new version it will be a new protocol. > > But, having said that, I note that the IANA just sent in an I-D on > port number allocation policy indicating that folks should be somewhat > cautious about blithely consuming port numbers. > > Yours, > Joel > > Margaret Wasserman wrote: >> >> In this discussion, I indicated that using a new port for a new >> version of LISP would work (technically), but that I didn't think it >> was the best choice. In general, I think it is better for a protocol >> to provide for its own versioning, rather than using up resources >> associated with a lower-layer protocol. >> >> Also, I have been thinking about this a bit more since then, and I >> wonder about the operational implications of using a new port for >> each new version of a higher-layer protocol... This means that if a >> site administrator wants to block (or enable) LISP in his firewall, >> he would have to keep track of new LISP versions and block (or >> accept) a new UDP port for each new version of LISP. >> >> So, while I'm not strongly religious on this topic, I think it would >> be better if LISP provided its own versioning field. >> >> If we choose to go with the plan that we'll use a new UDP port if we >> ever need a new version of LISP, I'd like us to explicitly document >> that, so that it is clear that this was an intentional choice. >> >> Margaret >> >> On Aug 12, 2009, at 3:51 PM, Sam Hartman wrote: >> >>> Discussion earlier on the list focused on whether there was a need for >>> an explicit lisp protocol version in the header. Several participants >>> argued that LISP could change its port if a new version was needed. >>> This issue tracks that discussion. >>> >>> Unless someone objects by August 20, I'll conclude that the consensus >>> of the WG is that no version is needed. >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From iljitsch@muada.com Wed Aug 19 03:01:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B893A69E0; Wed, 19 Aug 2009 03:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEfpZvD56mFh; Wed, 19 Aug 2009 03:01:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 77C093A6767; Wed, 19 Aug 2009 03:01:38 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7JA13qH056960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 12:01:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <69B21F02-D497-4C52-8E3C-E7C5B8D44535@muada.com> From: Iljitsch van Beijnum To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 12:01:30 +0200 References: <20090807193111.3BD9C6BE5C1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: ipv6@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 19 Aug 2009 10:01:39 -0000 On 11 aug 2009, at 16:09, Sam Hartman wrote: > We have not reached a consensus that LISP needs to work through NATs. > I'll take your message as a statement in favor of that and a personal > opinion that they need to. Please put me down in the "that's insane" column. From alexandru.petrescu@gmail.com Wed Aug 19 08:36:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9733A683A for ; Wed, 19 Aug 2009 08:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3BOCi4QY1os for ; Wed, 19 Aug 2009 08:36:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D86713A677D for ; Wed, 19 Aug 2009 08:36:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7JFar3Q013287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Aug 2009 17:36:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7JFaqiN031344; Wed, 19 Aug 2009 17:36:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n7JFaqQp006638; Wed, 19 Aug 2009 17:36:52 +0200 Message-ID: <4A8C1C14.3030503@gmail.com> Date: Wed, 19 Aug 2009 17:36:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Zwiebel References: <4A4E4724.5020207@joelhalpern.com> <9AE09228-7123-4759-BB6F-C5F43F3016CA@cisco.com> <4A4E6087.4090809@joelhalpern.com><53D1F202-326F-495C-8B84-70FAD92C604E@cisco.com><4A5C8E8B.1050305@gmail.com> <2B5F3EA7272CFF47A66518E4FF3BE23503B3CE5B@FIESEXC014.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] Mobile LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 19 Aug 2009 15:36:58 -0000 John Zwiebel a écrit : > > On Jul 24, 2009, at 12:50 AM, Flinck, Hannu (NSN - FI/Espoo) wrote: > >> >> I was wondering if you considered just having a mobile ip homeagent >> >> >> within a LISP site. >> > > Then it would be the same a the current mobile IP. No gain. Sorry, late reply. After reading the LISP and LISP-MN drafts I can't say that a pure LISP Mobile Node has any advantage over Mobile IP. I can understand the ossified Internet shortcomings that LISP addresses but I don't see the Mobile IP shortcomings that LISP-MN addresses. Worse, LISP-MN seems to always employ encapsulation and triangular routing, whereas Mobile IPv6 has some ways out of it. About the initial suggestion of H. Flinck - putting a HA in a LISP site - I think this case is described in the LISP draft-03 section 10.3, where is dscribed the use of Mobile IP[v6] simultaneously with LISP ITR and ETR. The section is not clear completely, I could remark on it separately. Alex > > > ------------------------------------------------------------------------ > > > _______________________________________________ lisp mailing list > lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From jzwiebel@cisco.com Wed Aug 19 21:02:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1143A6AE3 for ; Wed, 19 Aug 2009 21:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAAatxzm-QaJ for ; Wed, 19 Aug 2009 21:02:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 596C53A6A62 for ; Wed, 19 Aug 2009 21:02:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJZnjEqrR7PE/2dsb2JhbACCJy+5a4gvkUIFhBqBUw X-IronPort-AV: E=Sophos;i="4.43,412,1246838400"; d="scan'208,217";a="230365651" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Aug 2009 04:02:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7K42NW7027591; Wed, 19 Aug 2009 21:02:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7K42Nef019933; Thu, 20 Aug 2009 04:02:23 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 21:02:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA214B.05942033" Date: Wed, 19 Aug 2009 21:00:30 -0700 Message-ID: <1E1355AB5D71474AB186AE542E21AD17036951F7@xmb-sjc-22c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Mobile LISP Thread-Index: Acog4uW3Br0+u1NrR/eZc39KOXgsDwAZ9xoI References: <4A4E4724.5020207@joelhalpern.com> <9AE09228-7123-4759-BB6F-C5F43F3016CA@cisco.com> <4A4E6087.4090809@joelhalpern.com><53D1F202-326F-495C-8B84-70FAD92C604E@cisco.com><4A5C8E8B.1050305@gmail.com> <2B5F3EA7272CFF47A66518E4FF3BE23503B3CE5B@FIESEXC014.nsn-intra.net> <4A8C1C14.3030503@gmail.com> From: "John Zwiebel (jzwiebel)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Aug 2009 04:02:23.0733 (UTC) FILETIME=[05D10A50:01CA214B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2607; t=1250740943; x=1251604943; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20=22John=20Zwiebel=20(jzwiebel)=22=20 |Subject:=20RE=3A=20[lisp]=20Mobile=20LISP |Sender:=20; bh=7/03zABgo4blhntmg7tPSfAeoVDs7saG/N+OYZIFjqw=; b=NNAs5ILfxV1ehEjpzGxhDMi1bzF7q1S5qjFxrIAjW8Iy/4NHGRNr5UdOFi /73VPN02unUkX6/QKl5JZAwtG/pYhf945LQPZGan5e3tpABdsbyA9qEQvM4r 1OA2wSkT1M; Authentication-Results: sj-dkim-4; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Mobile LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 04:02:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA214B.05942033 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Wed 8/19/2009 8:36 AM To: John Zwiebel (jzwiebel) Cc: Flinck, Hannu (NSN - FI/Espoo); lisp@ietf.org Subject: Re: [lisp] Mobile LISP =20 John Zwiebel a =E9crit : Worse, LISP-MN seems to always employ encapsulation and triangular routing, whereas Mobile IPv6 has some ways out of it. Your "seems to" is mistaken. The call set up may require triangular routing but once each MN has the local RLOC, all=20 communication is direct between MNs >=20 >=20 > = ------------------------------------------------------------------------ >=20 >=20 > _______________________________________________ lisp mailing list=20 > lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ------_=_NextPart_001_01CA214B.05942033 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [lisp] Mobile LISP


-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gm= ail.com]
Sent: Wed 8/19/2009 8:36 AM
To: John Zwiebel (jzwiebel)
Cc: Flinck, Hannu (NSN - FI/Espoo); lisp@ietf.org
Subject: Re: [lisp] Mobile LISP

John Zwiebel a =E9crit :

Worse, LISP-MN seems to always employ encapsulation and triangular
routing, whereas Mobile IPv6 has some ways out of it.

<z> Your "seems to" is mistaken.
<z> The call set up may require triangular routing
<z> but once each MN has the local RLOC, all
<z> communication is direct between MNs

>
>
> = ------------------------------------------------------------------------<= BR> >
>
> _______________________________________________ lisp mailing = list
> lisp@ietf.org https://www.ietf.org/= mailman/listinfo/lisp

------_=_NextPart_001_01CA214B.05942033-- From alexandru.petrescu@gmail.com Thu Aug 20 01:30:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B255A3A6D35 for ; Thu, 20 Aug 2009 01:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75KQyqeUueWX for ; Thu, 20 Aug 2009 01:30:20 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C4DCF3A6CCC for ; Thu, 20 Aug 2009 01:30:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7K8UDwr023335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Aug 2009 10:30:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7K8UDdJ029194; Thu, 20 Aug 2009 10:30:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n7K8UCgu010187; Thu, 20 Aug 2009 10:30:13 +0200 Message-ID: <4A8D0994.5070901@gmail.com> Date: Thu, 20 Aug 2009 10:30:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "John Zwiebel (jzwiebel)" References: <4A4E4724.5020207@joelhalpern.com> <9AE09228-7123-4759-BB6F-C5F43F3016CA@cisco.com> <4A4E6087.4090809@joelhalpern.com><53D1F202-326F-495C-8B84-70FAD92C604E@cisco.com><4A5C8E8B.1050305@gmail.com> <2B5F3EA7272CFF47A66518E4FF3BE23503B3CE5B@FIESEXC014.nsn-intra.net> <4A8C1C14.3030503@gmail.com> <1E1355AB5D71474AB186AE542E21AD17036951F7@xmb-sjc-22c.amer.cisco.com> In-Reply-To: <1E1355AB5D71474AB186AE542E21AD17036951F7@xmb-sjc-22c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: lisp@ietf.org Subject: Re: [lisp] Mobile LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 08:30:20 -0000 John Zwiebel (jzwiebel) a écrit : > > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wed 8/19/2009 8:36 AM > To: John Zwiebel (jzwiebel) > Cc: Flinck, Hannu (NSN - FI/Espoo); lisp@ietf.org > Subject: Re: [lisp] Mobile LISP > > John Zwiebel a écrit : > > Worse, LISP-MN seems to always employ encapsulation and triangular > routing, whereas Mobile IPv6 has some ways out of it. > > Your "seems to" is mistaken. > The call set up may require triangular routing > but once each MN has the local RLOC, all > communication is direct between MNs John - but once the local RLOC is selected, thus allowing for direct communication, there is always LISP encapsulation, right? Alex From trac@tools.ietf.org Thu Aug 20 06:13:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4DA3A6CEC for ; Thu, 20 Aug 2009 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZO+92GHF3Zv for ; Thu, 20 Aug 2009 06:13:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id DB0803A6D79 for ; Thu, 20 Aug 2009 06:13:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Me7Sf-0006kX-7v; Thu, 20 Aug 2009 06:13:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "lisp issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: darlewis@cisco.com X-Trac-Project: lisp Date: Thu, 20 Aug 2009 13:13:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/6 Message-ID: <057.0b369985af6e874885dcbd3a7fc83468@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: darlewis@cisco.com, hartmans-ietf@mit.edu, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Thu, 20 Aug 2009 08:02:42 -0700 Cc: lisp@ietf.org Subject: [lisp] #6: LISP ITRs using value of 0 for UDP Checksum in IPv6 LISP outer header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Aug 2009 13:13:45 -0000 #6: LISP ITRs using value of 0 for UDP Checksum in IPv6 LISP outer header -------------------------------+-------------------------------------------- Reporter: darlewis@cisco.com | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: Checksum LISP -------------------------------+-------------------------------------------- Discussion on the list focused on whether the IPv6 UDP checksum could be sent/received as zero, and what the potential costs and benefits of this change would be. There was also a discussion of which RFCs would need to be updated if the LISP WG decided the IPv6 zero UDP checksum issue in favor of being able to transmit/receive a zero UDP checksum. Background: The LISP Draft authors chose to use UDP encapsulation and further to specify setting the checksum of these packets to 0 for several reasons. 1) The LISP authors received feedback very early (during the RRG meetings) that having LISP encapsulated flows be hashable by existing Link Aggregation hardware was critical. Which, in the hardware existing in large ISP networks, limits LISP to using either UDP or TCP protocols for IPv4 and IPv6. (ref msgs: Chris Morrow, Vince Fuller, and Shane Amante Joel Halpern) 2) The LISP authors feel that having to calculate the pseudo header checksum on encapsulation will impose an unreasonable burden on high speed (non commodity) encapsulation hardware. This then requires LISP to allow for encapsulating with 0 checksum datagrams in IPv4 and IPv6. (ref msg: Dino Farinacci, vince fuller, Joel Halpern). These requirements taken together prevent LISP from using other encapsulation types, which were suggested during the thread, including UDP-Lite, IP-IP (say GRE) encapsulation, etc. Some input from participants on thread on the WG list are included below, since they help summarize the outstanding issues and the impacts of this decision. ------------------- Margaret Wasserman contributed the following analysis: (text edited to focus on encapsulation issue) #1: Sending UDP Zero Checksums Violates RFC 2460 The use of zero UDP checksums in IPv6 is forbidden by RFC 2460. This issue could be addressed in one of two ways: (1) move to any standards-compliant encapsulation, or (2) include a normative reference to a standards-track document that updates RFC 2460 to allow UDP zero checksums. #2: Sending UDP Zero Checksums not Universally Implemented Current TCP/IP stacks do not always implement the ability to turn off UDP checksum calculation for outbound traffic. In some cases, this could be corrected by a software change. In other cases, the checksum may be calculated in hardware. It may not be possible to turn off UDP checksum calculation for outbound LISP traffic, without turning off UDP checksum calculation for all outbound traffic. This issue could be resolved by changing the text that indicates that LISP ITRs "MUST" send zero UDP checksums to a "MAY". #3: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis Research (the Stone/Partridge paper) and prior experience (with NFS and IS-IS, among others) have indicated that it is (at least sometimes) a very bad idea to disable and/or bypass UDP or IP checksums. References: Stone/Partridge Paper on Internet Checksums: http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm IS-IS Optional Checksum: http://www.rfc-editor.org/rfc/rfc3358.txt We have proposed disabling the IPv4 UDP checksum and effectively disabling both the IPv6 header and UDP checksum in IPv6. As part of making this decision in a responsible manner, we need to perform (and document) an analysis of the implications of that choice, both on LISP itself and on other nodes and applications that have to co-exist with LISP. #4: LAG/ECMP Requirements Not Well-Explained The LAC/ECMP requirements that drive some LISP design choices are not well-explained in the draft. This issue was raised by Sam Hartman, and Dino agreed to add additional text. ------------------ Sam Hartman Contributed the following summary of general requirements for LISP encapsulation: Requirements participants have stated include: * Works with LAGs/ECMP * Implementable in router hardware * Implementable on stock TCP/IP stacks * Implementable using server/desktop NICs with checksum offload * Can be easily deployed * Works through firewalls and NATs We have not yet judged formally whether some or all of these requirements are important to the WG as a whole. We may b e able to move forward without that although refocusing on the requirements is certainly a tool that is available to us. -- Ticket URL: lisp LISP WG document issues From trac@tools.ietf.org Thu Aug 20 06:37:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07BA3A6D4E for ; Thu, 20 Aug 2009 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9Xv2NsEdx7Y for ; Thu, 20 Aug 2009 06:37:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id D74073A6CDA for ; Thu, 20 Aug 2009 06:37:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Me7pF-000575-29; Thu, 20 Aug 2009 06:37:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "lisp issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: darlewis@cisco.com X-Trac-Project: lisp Date: Thu, 20 Aug 2009 13:37:08 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/7 Message-ID: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: darlewis@cisco.com, hartmans-ietf@mit.edu, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Thu, 20 Aug 2009 08:02:42 -0700 Cc: lisp@ietf.org Subject: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Aug 2009 13:37:04 -0000 #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation -------------------------------+-------------------------------------------- Reporter: darlewis@cisco.com | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: LISP Decapsulation Checksum -------------------------------+-------------------------------------------- Discussion on the list focused on whether the IPv4/IPv6 UDP checksum may be ignored when received as a non-zero, and what the potential costs and benefits of this behavior would be. There was also a discussion of which RFCs this violates and would need to be updated if the LISP WG decided that not checking IPv4/IPv6 checksums was an acceptable behavior. Background: The LISP Draft authors chose to specify that an ETR ignore the UDP checksum on receipt/decapsualtion of a LISP packet. The reasons mentioned on the LISP for this were: 1) Ease of implementation. Since checksums were not typically used on encapsulation (see issue tracker ticket #6) they aren't considered critical for LISP. 2) Some NAT devices will ignore the UDP packet's 0 checksum, and re- calculate and add a new checksum when translating the packet. This prevented the ETR requiring the packet's checksum be 0. There was a report that some (older) IPv4 NATs incorrectly did this calculation. Some input from participants on thread on the WG list are included below, since they help summarize the outstanding issues and the potential impacts of the authors original decision. ------------------- Margaret Wasserman contributed the following analysis: (text edited to focus on checksum decapsulation issue) #1: Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 and RFC 2460 Not checking non-zero UDP checksums on inbound traffic (at the ETR in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6). There is concern that checking the checksums would cause two problems: performance issues for existing routers that lacks the ability to perform the checksum efficiently, and problems when the zero UDP checksums themselves are corrupted en route (particularly by poorly implemented NAT boxes). This issue could be addressed in one of two ways: (1) require standards-compliant behavior in LISP ETRs, or include a normative reference to a standards-track RFC that updates RFC 1122 and RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums. #2: Not Checking Inbound Non-Zero Checksums not Universally Implemented. There are TCP/IP stacks that do not have any way to turn off checking of non-zero UDP checksums on receipt. If this functionality can be turned off, it may not be possible to turn it off for LISP traffic only , while it remains enabled for other traffic. Also, the checksum may be checked in hardware before the software sees the packet. This issue could be resolved by changing the text that indicates that LISP ETRs "MUST" ignore incoming UDP checksums to a "MAY". ----------- Sam Hartman suggested text, and Dino Farinacci responded: On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. Anyone object to me putting this text in the -04 spec now? -- Ticket URL: lisp LISP WG document issues From darlewis@cisco.com Thu Aug 20 08:12:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA5D3A701E for ; Thu, 20 Aug 2009 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHaAab8qEvNq for ; Thu, 20 Aug 2009 08:12:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B6C333A701C for ; Thu, 20 Aug 2009 08:12:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ8EjUqrR7PD/2dsb2JhbAC+bYgvkSQFhBg X-IronPort-AV: E=Sophos;i="4.43,415,1246838400"; d="scan'208";a="230649191" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Aug 2009 15:12:11 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7KFCBi8002025; Thu, 20 Aug 2009 08:12:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7KFCBlJ016968; Thu, 20 Aug 2009 15:12:11 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 08:12:10 -0700 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, 20 Aug 2009 08:12:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 75 LISP WG minutes posted Thread-Index: AcohqJZ/Ckbv9eyzRgWYJeLPIIkmQA== From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 20 Aug 2009 15:12:11.0023 (UTC) FILETIME=[974ED9F0:01CA21A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=215; t=1250781131; x=1251645131; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20IETF=2075=20LISP=20WG=20minutes=20posted |Sender:=20; bh=Ke+jumsXWExN/1Y3I4hNGeMKapHE6smsP+3D0IhClzg=; b=lMCBcmCf97dZ6/5HVq4uIQ/6PEubWNMn9Ngtwq592czM/vQVHRpdMy6o4u QlssRYD2UWQbB6+1QuyqU02RiVoO+kcV8pWOV5s+ozpKMW4tdIU05eFQuVXT 5F8qQMcHnP; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] IETF 75 LISP WG minutes posted X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 15:12:38 -0000 All, The minutes for the Stockhom meeting have been posted and are available at: http://www.ietf.org/proceedings/75/minutes/lisp.txt Please send any comments/corrections to the chairs, thanks. -Darrel From mrw@sandstorm.net Thu Aug 20 10:57:02 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6488828C16B for ; Thu, 20 Aug 2009 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8VGquLSNJcR for ; Thu, 20 Aug 2009 10:57:01 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4AF773A6AB3 for ; Thu, 20 Aug 2009 10:57:01 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7KHtfOM074211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 13:55:42 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> From: Margaret Wasserman To: trac@localhost.amsl.com In-Reply-To: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 20 Aug 2009 13:55:41 -0400 References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 17:57:02 -0000 Hi Darrel, Thank you for attempting to enter the issues that I sent into the tracker, but I think that there has been some mistake... I was asked, by multiple people on the list, to make a distinction between the different issues that were raised as part of the UDP checksum discussion, and I went to some trouble to review the entire discussion and call out what I considered to be the _7_ separate issues that were raised during the discussion. It was not my intention that this would result in two tracker issues, one that covers two of the issues from my list, and one that covers four of them. (Is there still an issue coming that covers the 7th?). Please correct this mistake by opening seven issues that match my original mail. I'm also somewhat put off by the fact that these issue entries include the authors' justification for the current text _before_ they even state the issue that was raised. Is writing up these justifications what made it take _over a week_ for my issues to be entered into the tracker at all? Margaret On Aug 20, 2009, at 9:37 AM, lisp issue tracker wrote: > #7: LISP ETRs ignoring checksum value in LISP UDP outer header on > decapsulation > ------------------------------- > +-------------------------------------------- > Reporter: darlewis@cisco.com | Owner: > Type: technical | Status: new > Priority: major | Component: draft-ietf-lisp > Severity: - | Keywords: LISP Decapsulation > Checksum > ------------------------------- > +-------------------------------------------- > Discussion on the list focused on whether the IPv4/IPv6 UDP checksum > may > be ignored when received as a non-zero, and what the potential costs > and > benefits of this behavior would be. There was also a discussion of > which > RFCs this violates and would need to be updated if the LISP WG decided > that not checking IPv4/IPv6 checksums was an acceptable behavior. > > Background: > > The LISP Draft authors chose to specify that an ETR ignore the UDP > checksum on receipt/decapsualtion of a LISP packet. The reasons > mentioned > on the LISP for this were: > > 1) Ease of implementation. Since checksums were not typically used on > encapsulation (see issue tracker ticket #6) they aren't considered > critical for LISP. > > 2) Some NAT devices will ignore the UDP packet's 0 checksum, and re- > calculate and add a new checksum when translating the packet. This > prevented the ETR requiring the packet's checksum be 0. There was a > report that some (older) IPv4 NATs incorrectly did this calculation. > > Some input from participants on thread on the WG list are included > below, > since they help summarize the outstanding issues and the potential > impacts > of the authors original decision. > > ------------------- > > Margaret Wasserman contributed the following analysis: > (text edited to focus on checksum decapsulation issue) > > > #1: Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 > and RFC > 2460 Not checking non-zero UDP checksums on inbound traffic (at the > ETR > in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6). > There is > concern that checking the checksums would cause two problems: > performance issues for existing routers that lacks the ability to > perform the checksum efficiently, and problems when the zero UDP > checksums themselves are corrupted en route (particularly by poorly > implemented NAT boxes). This issue could be addressed in one of two > ways: (1) require standards-compliant behavior in LISP ETRs, or > include > a normative reference to a standards-track RFC that updates RFC > 1122 and > RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums. > > #2: Not Checking Inbound Non-Zero Checksums not Universally > Implemented. > > There are TCP/IP stacks that do not have any way to turn off > checking of > non-zero UDP checksums on receipt. If this functionality can be > turned > off, it may not be possible to turn it off for LISP traffic only , > while > it remains enabled for other traffic. Also, the checksum may be > checked > in hardware before the software sees the packet. This issue could be > resolved by changing the text that indicates that LISP ETRs "MUST" > ignore > incoming UDP checksums to a "MAY". > > ----------- > > Sam Hartman suggested text, and Dino Farinacci responded: > > On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: > > You'd need to word it as an ITR MAY send a zero checksum, an ETR > MUST accept a 0 checksum and MAY ignore the checksum completely. > > Anyone object to me putting this text in the -04 spec now? > > -- > Ticket URL: > lisp > LISP WG document issues > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac@tools.ietf.org Thu Aug 20 11:45:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9127F3A68D2 for ; Thu, 20 Aug 2009 11:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Yx6FycW1eXS for ; Thu, 20 Aug 2009 11:44:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7AD493A6830 for ; Thu, 20 Aug 2009 11:44:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MeCd0-0001go-1m; Thu, 20 Aug 2009 11:44:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "lisp issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: mrw@lilacglade.org X-Trac-Project: lisp Date: Thu, 20 Aug 2009 18:44:50 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/8 Message-ID: <057.f7859e8374c6706ab9e7038622264226@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mrw@lilacglade.org, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 20 Aug 2009 18:45:03 -0000 #8: Limits on "Gleaned" Map Entries Not Clear -------------------------------+-------------------------------------------- Reporter: mrw@lilacglade.org | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail. -- Ticket URL: lisp LISP WG document issues From dmm@1-4-5.net Thu Aug 20 12:07:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E4C3A6A0C for ; Thu, 20 Aug 2009 12:07:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLtUI51biKRO for ; Thu, 20 Aug 2009 12:07:08 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 210D63A6839 for ; Thu, 20 Aug 2009 12:07:08 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n7KJ77E3026312; Thu, 20 Aug 2009 12:07:07 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n7KJ76Lb026311; Thu, 20 Aug 2009 12:07:06 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 20 Aug 2009 12:07:06 -0700 From: David Meyer To: Margaret Wasserman Message-ID: <20090820190706.GA26084@1-4-5.net> References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:07:09 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Margaret, > Hi Darrel, > > Thank you for attempting to enter the issues that I sent into the =20 > tracker, but I think that there has been some mistake... > > I was asked, by multiple people on the list, to make a distinction =20 > between the different issues that were raised as part of the UDP =20 > checksum discussion, and I went to some trouble to review the entire =20 > discussion and call out what I considered to be the _7_ separate issues= =20 > that were raised during the discussion. It was not my intention that=20 > this would result in two tracker issues, one that covers two of the=20 > issues from my list, and one that covers four of them. (Is there still= =20 > an issue coming that covers the 7th?). Please correct this mistake by=20 > opening seven issues that match my original mail. > > I'm also somewhat put off by the fact that these issue entries include = =20 > the authors' justification for the current text _before_ they even state= =20 > the issue that was raised. Is writing up these justifications what made= =20 > it take _over a week_ for my issues to be entered into the tracker at=20 > all? It seems there are a misunderstandings here. First, both Darrel and I read the tracker procedure Sam posted to say that only the authors, WG chairs, or the WG secretary could open issues in the LISP tracker; see for example the email included below (Message-ID: ). So Darrel was trying to get your issues into the tracker on the assumption that you couldn't do it yourself; issue #8 (#8: Limits on "Gleaned" Map Entries Not Clear) suggests that you can indeed add your own issues so that assumption was apparently false.=20 Second, Darrel and I discussed whether it would be correct to open an issue for each of your seven issues or to summarize. Since it was unclear that you wanted seven issues opened, we summarized (on the theory that such summarization would help the group resolve the issues more efficiently). In any event, I see that you intended that each be opened as a separate issue. Now the question is how would you like to resolve this? The reason I ask is that one approach would be just to cut and paste from your email and if possible, cross reference the relevant issue that Darrel opened to the newly created one. I'm not sure if the tracker can do that. Alternatively, if the tracker can delete an issue, then we can just open 6 new ones (#8 is what I believe was #7 in your original list). This is a relatively simple process issue that should be easy to resolve, and I'm glad to help you and/or the chairs do so. Just let me know if I can help. Dave =09 ---- =46rom: Sam Hartman To: Noel Chiappa Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker Date: Tue, 11 Aug 2009 17:26:49 -0400 Can we please wait until the authors or secretary opens these issues and assigns numbers before discussing in this thread? _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqNntoACgkQORgD1qCZ2KcDMgCfWjYu5BNriLl5V0FcJTPeV9jt /f8An22mn4gwq2IEt1nSVY8NxnV8fXFY =BhLH -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From mrw@sandstorm.net Thu Aug 20 12:15:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD82E3A6AEA for ; Thu, 20 Aug 2009 12:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEwdMAj6C2i3 for ; Thu, 20 Aug 2009 12:15:47 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B64D63A6AC4 for ; Thu, 20 Aug 2009 12:15:47 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7KJFTM2078626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 15:15:29 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: David Meyer In-Reply-To: <20090820190706.GA26084@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 20 Aug 2009 15:15:28 -0400 References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <20090820190706.GA26084@1-4-5.net> X-Mailer: Apple Mail (2.935.3) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:15:48 -0000 Hi Dave, On Aug 20, 2009, at 3:07 PM, David Meyer wrote: > It seems there are a misunderstandings here. First, both > Darrel and I read the tracker procedure Sam posted to say > that only the authors, WG chairs, or the WG secretary > could open issues in the LISP tracker; see for example > the email included below (Message-ID: ). > So Darrel was trying to get your issues into the tracker > on the assumption that you couldn't do it yourself; issue > #8 (#8: Limits on "Gleaned" Map Entries Not Clear) > suggests that you can indeed add your own issues so that > assumption was apparently false. I can't add issues to the tracker, and I didn't add issue #8. I assumed that Darrel did so in response to my mail... > > Second, Darrel and I discussed whether it would be > correct to open an issue for each of your seven issues or > to summarize. Since it was unclear that you wanted seven > issues opened, we summarized (on the theory that such > summarization would help the group resolve the issues > more efficiently). > > In any event, I see that you intended that each be opened > as a separate issue. Now the question is how would you > like to resolve this? The reason I ask is that one > approach would be just to cut and paste from your email > and if possible, cross reference the relevant issue that > Darrel opened to the newly created one. I'm not sure if > the tracker can do that. Alternatively, if the tracker > can delete an issue, then we can just open 6 new ones (#8 > is what I believe was #7 in your original list). I'm not sure what the best way forward would be (from a tracker organization standpoint), because I don't know how this tracker system works. But I do think it is important that we separate issues for that separate questions that were raised. For example, there seemed to be a lot of confusion about the discussion of RFC 2460 compliance, since it got all entangled with the discussion of whether turning off IPv6 UDP checksums is the right thing to do, technically. I think we need to decide on the right technical choice (based on the interests of the whole Internet, not just LISP). Then, if our choice is at odds with an IETF standards track or BCP RFC, we will need to figure out how to get that RFC updated. Of course, this all very complex on the UDP checksum issue, because there are a lot of other people involved in deciding what the right technical choice is, and there are already proposals out there to change the existing RFCs. Because of all of this, I thought it would best to make these issues explicitly separate. Perhaps we could just open 6 separate issues and then close the two that were opened as duplicates of (at least some of) the other 6, assuming the tracker will support that? Margaret From hartmans@mit.edu Thu Aug 20 12:16:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708A43A6839 for ; Thu, 20 Aug 2009 12:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V30qQ6k4nStM for ; Thu, 20 Aug 2009 12:16:58 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 304723A6E28 for ; Thu, 20 Aug 2009 12:16:57 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CCECD641DA; Thu, 20 Aug 2009 15:17:00 -0400 (EDT) To: Margaret Wasserman References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> From: Sam Hartman Date: Thu, 20 Aug 2009 15:17:00 -0400 In-Reply-To: <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> (Margaret Wasserman's message of "Thu\, 20 Aug 2009 13\:55\:41 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:16:59 -0000 Darrel, One of the nice things that Margaret did in her initial issue write-ups was separate the technical issues from the process issues. For me as the chair who will be judging consensus on these, that actually helps a lot. I can ask the WG to focus on the technical issues and once we have resolution there,then confirm that we're good on the process issues. The way in which you have entered the issues manages to lose that. I agree with Margaret that the background text is problematic. I can understand adding some context to an issue so that someone reading the issue can understand what the issue is. For example if we were having a discussion in which I said "Md5 is a bad choice; we should use sha-256 instead because it does not suffer from the collision attacks that have been demonstrated against md5," it would be entirely reasonable to add context explaining where we were using md5 when opening an issue. However I agree with Margaret that it is generally a bad idea to add an explanation of why the current text is the way it is to an issue someone else has reported. It's way too easy for editors to use that to give way too much weight to their own personal opinions as individual contributors. It's possible that if you were very careful to maintain a neutral tone you could make this work, but it's definitely not worth the effort. In this specific instance, you stated several things as requirements--NAT traversal, support for LAGs--that we have not decided as a WG actually are requirements. I understand that a significant subset of the WG, including the authors of the drafts that form the basis for our work, believe these are requirements. I don't think we can have a WG discussion of this until we have the discussion of LISP deployment models that you and I discussed the other day. It's really important that when you're acting as an editor or as a chair, you maintain a neutral tone. A better approach is to respond as an individual contributor explaining in your opinion why the text is the way it is; often it will be appropriate to include this in the tracker as a comment. The point of the issue in the tracker is to explain what the person who has reported the issue believes is wrong with the document and how they propose to improve it. The point of the following discussion is to evaluate whether this is true. Also, especially if we're going to try and have issue discussions in threads with the issue number, it's really important that we open issues promptly. While I appreciate that you were trying to combine both the issue opening and discussion summary steps, I think it would have been better to just cut&paste the issues quickly and then defer the summarization of the discussion. From hartmans@mit.edu Thu Aug 20 12:19:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896D928C1BA for ; Thu, 20 Aug 2009 12:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN5Om5xOKpbN for ; Thu, 20 Aug 2009 12:19:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 3179928C0E9 for ; Thu, 20 Aug 2009 12:19:18 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A4BA5641DA; Thu, 20 Aug 2009 15:19:21 -0400 (EDT) To: Margaret Wasserman References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <20090820190706.GA26084@1-4-5.net> From: Sam Hartman Date: Thu, 20 Aug 2009 15:19:21 -0400 In-Reply-To: (Margaret Wasserman's message of "Thu\, 20 Aug 2009 15\:15\:28 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:19:45 -0000 I opened issue #8 in my role as WG chair. From dmm@1-4-5.net Thu Aug 20 12:21:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9F828C1BA for ; Thu, 20 Aug 2009 12:21:26 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT3cb65mrh9p for ; Thu, 20 Aug 2009 12:21:25 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 695C528C0E9 for ; Thu, 20 Aug 2009 12:21:25 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n7KJLOvs027209; Thu, 20 Aug 2009 12:21:24 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n7KJLOvL027208; Thu, 20 Aug 2009 12:21:24 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 20 Aug 2009 12:21:24 -0700 From: David Meyer To: Margaret Wasserman Message-ID: <20090820192124.GA27067@1-4-5.net> References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <20090820190706.GA26084@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: trac@localhost.amsl.com, lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:21:26 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2009 at 03:15:28PM -0400, Margaret Wasserman wrote: > > Hi Dave, > > On Aug 20, 2009, at 3:07 PM, David Meyer wrote: >> It seems there are a misunderstandings here. First, both >> Darrel and I read the tracker procedure Sam posted to say >> that only the authors, WG chairs, or the WG secretary >> could open issues in the LISP tracker; see for example >> the email included below (Message-ID: ). >> So Darrel was trying to get your issues into the tracker >> on the assumption that you couldn't do it yourself; issue >> #8 (#8: Limits on "Gleaned" Map Entries Not Clear) >> suggests that you can indeed add your own issues so that >> assumption was apparently false. > > I can't add issues to the tracker, and I didn't add issue #8. I assumed= =20 > that Darrel did so in response to my mail... Humm, ok. I have to admit I'm not well versed in tracker usage. >> Second, Darrel and I discussed whether it would be >> correct to open an issue for each of your seven issues or >> to summarize. Since it was unclear that you wanted seven >> issues opened, we summarized (on the theory that such >> summarization would help the group resolve the issues >> more efficiently). >> >> In any event, I see that you intended that each be opened >> as a separate issue. Now the question is how would you >> like to resolve this? The reason I ask is that one >> approach would be just to cut and paste from your email >> and if possible, cross reference the relevant issue that >> Darrel opened to the newly created one. I'm not sure if >> the tracker can do that. Alternatively, if the tracker >> can delete an issue, then we can just open 6 new ones (#8 >> is what I believe was #7 in your original list). > > I'm not sure what the best way forward would be (from a tracker =20 > organization standpoint), because I don't know how this tracker system = =20 > works. =20 Me either. > But I do think it is important that we separate issues for that=20 > separate questions that were raised. For example, there seemed to be a= =20 > lot of confusion about the discussion of RFC 2460 compliance, since it=20 > got all entangled with the discussion of whether turning off IPv6 UDP=20 > checksums is the right thing to do, technically. I think we need to=20 > decide on the right technical choice (based on the interests of the whole= =20 > Internet, not just LISP). Then, if our choice is at odds with an IETF=20 > standards track or BCP RFC, we will need to figure out how to get that=20 > RFC updated. Of course, this all very complex on the UDP checksum issue,= =20 > because there are a lot of other people involved in deciding what the=20 > right technical choice is, and there are already proposals out there to= =20 > change the existing RFCs. Because of all of this, I thought it would=20 > best to make these issues explicitly separate. Well taken. > > Perhaps we could just open 6 separate issues and then close the two that= =20 > were opened as duplicates of (at least some of) the other 6, assuming the= =20 > tracker will support that? That seems completely reasonable. Hopefully someone who knows if that can be done will answer up. Thanks for the comments, Dave --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqNojQACgkQORgD1qCZ2KfzbQCgghPPd2VJzytY7kIqabIfnzXp 60UAmwfxtGEcDSNUhhCw9IGzVVwpfF5/ =AZxY -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From darlewis@cisco.com Thu Aug 20 12:40:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D477D3A6A3B for ; Thu, 20 Aug 2009 12:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9WuMXHEkyeW for ; Thu, 20 Aug 2009 12:40:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 12B9428C0F0 for ; Thu, 20 Aug 2009 12:40:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAFDjUqrR7O6/2dsb2JhbAC/R4gvkQwFhBiBVA X-IronPort-AV: E=Sophos;i="4.43,416,1246838400"; d="scan'208";a="197450210" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2009 19:40:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7KJeBXb022890; Thu, 20 Aug 2009 12:40:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7KJeBvt011243; Thu, 20 Aug 2009 19:40:11 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 12:40:08 -0700 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, 20 Aug 2009 12:40:05 -0700 Message-ID: In-Reply-To: <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation Thread-Index: Acohv6Gnl7Nh+cC7Q5uExO76dUAW3wABA//A References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> From: "Darrel Lewis (darlewis)" To: "Margaret Wasserman" X-OriginalArrivalTime: 20 Aug 2009 19:40:08.0784 (UTC) FILETIME=[06667D00:01CA21CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7564; t=1250797211; x=1251661211; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20#7=3A=20LISP=20ETRs=20ignoring =20checksum=20value=20in=20LISP=20UDP=20outer=20header=20on= 20decapsulation |Sender:=20; bh=ndY0+I3AlmpooKrkA3sUCYCnF19TxiP4yvcjH6PQ/6M=; b=FUQMC8NeGA6z1ipr7lrDMTV9z6jTRm2t7jLSKl88qW2KElp/7xytiVxb9y +nUWS6+vupXtDhO0JA5v+pDkuMzsVwwlUEIkoGKwAQXiVvU/1VGhQujzVOs7 aivJNVJGBx; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 19:40:08 -0000 Margaret, The below message with my author's hat on, rather than as a WG co-chair. So speaking as an author, let me articulate why I opened the issues the way I did, and see if I can address some of your concerns below. However if you feel that you'd like each of your issues directly (and they need to be opened in a more timely manner), then perhaps its better to have individual WG members open their own issues. When thinking about what would be useful for the issue, I wanted to have each open ticket do the following: 1) general description of the issue in the title 2) spec viewpoint (why the text in the draft says what it says) 3) list of important points of view/criticism from list of that viewpoint 4) resolution of problem (if exists yet) Dave and I conferred and came up with the idea was that the tracker ticket would provide a central location for capturing the main themes of the thread/issue. In my mind, that included the original concept, the comments/criticisms and the possible resolutions. That way, if the issue came up again one could refer the questioner to the tracker to explain the facets of the solution. =20 So that was my intent in opening up the issues. I attempted to be neutral in describing the motivation for the text being involved, and reference relevant mails summarizing the issues. I hadn't opened your gleaning issue yet because I didn't fully understand the thread and wanted to ask you for clarifications first. =20 However, if merely cutting and pasting your email into 7 tickets is what the Sam and the WG feels is best, that's fine by me, it certainly won't take as long to open tickets. -Darrel > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@sandstorm.net]=20 > Sent: Thursday, August 20, 2009 10:56 AM > To: trac@localhost.amsl.com > Cc: Darrel Lewis (darlewis); lisp@ietf.org > Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in=20 > LISP UDP outer header on decapsulation >=20 >=20 > Hi Darrel, >=20 > Thank you for attempting to enter the issues that I sent into the =20 > tracker, but I think that there has been some mistake... >=20 > I was asked, by multiple people on the list, to make a distinction =20 > between the different issues that were raised as part of the UDP =20 > checksum discussion, and I went to some trouble to review the entire =20 > discussion and call out what I considered to be the _7_ separate =20 > issues that were raised during the discussion. It was not my =20 > intention that this would result in two tracker issues, one that =20 > covers two of the issues from my list, and one that covers four of =20 > them. (Is there still an issue coming that covers the 7th?).=20 > Please =20 > correct this mistake by opening seven issues that match my original =20 > mail. >=20 > I'm also somewhat put off by the fact that these issue=20 > entries include =20 > the authors' justification for the current text _before_ they even =20 > state the issue that was raised. Is writing up these justifications =20 > what made it take _over a week_ for my issues to be entered into the =20 > tracker at all? >=20 > Margaret >=20 >=20 > On Aug 20, 2009, at 9:37 AM, lisp issue tracker wrote: >=20 > > #7: LISP ETRs ignoring checksum value in LISP UDP outer header on =20 > > decapsulation > > -------------------------------=20 > > +-------------------------------------------- > > Reporter: darlewis@cisco.com | Owner: > > Type: technical | Status: new > > Priority: major | Component: draft-ietf-lisp > > Severity: - | Keywords: LISP Decapsulation =20 > > Checksum > > -------------------------------=20 > > +-------------------------------------------- > > Discussion on the list focused on whether the IPv4/IPv6 UDP=20 > checksum =20 > > may > > be ignored when received as a non-zero, and what the=20 > potential costs =20 > > and > > benefits of this behavior would be. There was also a discussion of =20 > > which > > RFCs this violates and would need to be updated if the LISP=20 > WG decided > > that not checking IPv4/IPv6 checksums was an acceptable behavior. > > > > Background: > > > > The LISP Draft authors chose to specify that an ETR ignore the UDP > > checksum on receipt/decapsualtion of a LISP packet. The reasons =20 > > mentioned > > on the LISP for this were: > > > > 1) Ease of implementation. Since checksums were not=20 > typically used on > > encapsulation (see issue tracker ticket #6) they aren't considered > > critical for LISP. > > > > 2) Some NAT devices will ignore the UDP packet's 0 checksum, and re- > > calculate and add a new checksum when translating the packet. This > > prevented the ETR requiring the packet's checksum be 0. There was a > > report that some (older) IPv4 NATs incorrectly did this calculation. > > > > Some input from participants on thread on the WG list are included =20 > > below, > > since they help summarize the outstanding issues and the potential =20 > > impacts > > of the authors original decision. > > > > ------------------- > > > > Margaret Wasserman contributed the following analysis: > > (text edited to focus on checksum decapsulation issue) > > > > > > #1: Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 =20 > > and RFC > > 2460 Not checking non-zero UDP checksums on inbound=20 > traffic (at the =20 > > ETR > > in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6). =20 > > There is > > concern that checking the checksums would cause two problems: > > performance issues for existing routers that lacks the ability to > > perform the checksum efficiently, and problems when the zero UDP > > checksums themselves are corrupted en route (particularly by poorly > > implemented NAT boxes). This issue could be addressed in one of two > > ways: (1) require standards-compliant behavior in LISP ETRs, or =20 > > include > > a normative reference to a standards-track RFC that updates RFC =20 > > 1122 and > > RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums. > > > > #2: Not Checking Inbound Non-Zero Checksums not Universally =20 > > Implemented. > > > > There are TCP/IP stacks that do not have any way to turn off =20 > > checking of > > non-zero UDP checksums on receipt. If this functionality can be =20 > > turned > > off, it may not be possible to turn it off for LISP traffic only , =20 > > while > > it remains enabled for other traffic. Also, the checksum may be =20 > > checked > > in hardware before the software sees the packet. This=20 > issue could be > > resolved by changing the text that indicates that LISP ETRs "MUST" =20 > > ignore > > incoming UDP checksums to a "MAY". > > > > ----------- > > > > Sam Hartman suggested text, and Dino Farinacci responded: > > > > On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: > > > > You'd need to word it as an ITR MAY send a zero=20 > checksum, an ETR > > MUST accept a 0 checksum and MAY ignore the checksum completely. > > > > Anyone object to me putting this text in the -04 spec now? > > > > --=20 > > Ticket URL: > > lisp > > LISP WG document issues > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 From jmh@joelhalpern.com Thu Aug 20 13:36:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32ACA3A6F6B for ; Thu, 20 Aug 2009 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxuS6EXVx6wz for ; Thu, 20 Aug 2009 13:36:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 08B953A6CF5 for ; Thu, 20 Aug 2009 13:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B3DBB43801A; Thu, 20 Aug 2009 13:37:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-13.clppva.btas.verizon.net [71.161.51.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7EA01438018; Thu, 20 Aug 2009 13:37:02 -0700 (PDT) Message-ID: <4A8DB3EC.8050908@joelhalpern.com> Date: Thu, 20 Aug 2009 16:37:00 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Darrel Lewis (darlewis)" References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 20:36:59 -0000 This WG can do something different, but in most WGs that use trackers, "spec viewpoint" is not part of the base item. The problem statement is just that, the problem statement. Discussion is then included as separate items, typically because the tracker picks up the discussion as long as the tracker number is in the subject. One of the points of this is to avoid biasing the entry either towards or away from any specific resolution. We all know that it works better to separate the problems from the solution. It also helps avoid defensiveness on the part of the author (or of the issue raiser) if they know that they are not expected or even allowed, to defend themselves. The existing text relative to an issue may be perfect. But the issue has been raised. It needs to be discussed and resolved. Yours, Joel Darrel Lewis (darlewis) wrote: > Margaret, > > The below message with my author's hat on, rather than as a WG co-chair. > > > So speaking as an author, let me articulate why I opened the issues the > way I did, and see if I can address some of your concerns below. > However if you feel that you'd like each of your issues directly (and > they need to be opened in a more timely manner), then perhaps its better > to have individual WG members open their own issues. > > When thinking about what would be useful for the issue, I wanted to have > each open ticket do the following: > > 1) general description of the issue in the title > 2) spec viewpoint (why the text in the draft says what it says) > 3) list of important points of view/criticism from list of that > viewpoint > 4) resolution of problem (if exists yet) > > Dave and I conferred and came up with the idea was that the tracker > ticket would provide a central location for capturing the main themes of > the thread/issue. In my mind, that included the original concept, the > comments/criticisms and the possible resolutions. That way, if the > issue came up again one could refer the questioner to the tracker to > explain the facets of the solution. > > So that was my intent in opening up the issues. I attempted to be > neutral in describing the motivation for the text being involved, and > reference relevant mails summarizing the issues. I hadn't opened your > gleaning issue yet because I didn't fully understand the thread and > wanted to ask you for clarifications first. > > However, if merely cutting and pasting your email into 7 tickets is what > the Sam and the WG feels is best, that's fine by me, it certainly won't > take as long to open tickets. > > -Darrel > > >> -----Original Message----- >> From: Margaret Wasserman [mailto:mrw@sandstorm.net] >> Sent: Thursday, August 20, 2009 10:56 AM >> To: trac@localhost.amsl.com >> Cc: Darrel Lewis (darlewis); lisp@ietf.org >> Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in >> LISP UDP outer header on decapsulation >> >> >> Hi Darrel, >> >> Thank you for attempting to enter the issues that I sent into the >> tracker, but I think that there has been some mistake... >> >> I was asked, by multiple people on the list, to make a distinction >> between the different issues that were raised as part of the UDP >> checksum discussion, and I went to some trouble to review the entire >> discussion and call out what I considered to be the _7_ separate >> issues that were raised during the discussion. It was not my >> intention that this would result in two tracker issues, one that >> covers two of the issues from my list, and one that covers four of >> them. (Is there still an issue coming that covers the 7th?). >> Please >> correct this mistake by opening seven issues that match my original >> mail. >> >> I'm also somewhat put off by the fact that these issue >> entries include >> the authors' justification for the current text _before_ they even >> state the issue that was raised. Is writing up these justifications >> what made it take _over a week_ for my issues to be entered into the >> tracker at all? >> >> Margaret >> >> >> On Aug 20, 2009, at 9:37 AM, lisp issue tracker wrote: >> >>> #7: LISP ETRs ignoring checksum value in LISP UDP outer header on >>> decapsulation >>> ------------------------------- >>> +-------------------------------------------- >>> Reporter: darlewis@cisco.com | Owner: >>> Type: technical | Status: new >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Keywords: LISP Decapsulation >>> Checksum >>> ------------------------------- >>> +-------------------------------------------- >>> Discussion on the list focused on whether the IPv4/IPv6 UDP >> checksum >>> may >>> be ignored when received as a non-zero, and what the >> potential costs >>> and >>> benefits of this behavior would be. There was also a discussion of >>> which >>> RFCs this violates and would need to be updated if the LISP >> WG decided >>> that not checking IPv4/IPv6 checksums was an acceptable behavior. >>> >>> Background: >>> >>> The LISP Draft authors chose to specify that an ETR ignore the UDP >>> checksum on receipt/decapsualtion of a LISP packet. The reasons >>> mentioned >>> on the LISP for this were: >>> >>> 1) Ease of implementation. Since checksums were not >> typically used on >>> encapsulation (see issue tracker ticket #6) they aren't considered >>> critical for LISP. >>> >>> 2) Some NAT devices will ignore the UDP packet's 0 checksum, and re- >>> calculate and add a new checksum when translating the packet. This >>> prevented the ETR requiring the packet's checksum be 0. There was a >>> report that some (older) IPv4 NATs incorrectly did this calculation. >>> >>> Some input from participants on thread on the WG list are included >>> below, >>> since they help summarize the outstanding issues and the potential >>> impacts >>> of the authors original decision. >>> >>> ------------------- >>> >>> Margaret Wasserman contributed the following analysis: >>> (text edited to focus on checksum decapsulation issue) >>> >>> >>> #1: Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 >>> and RFC >>> 2460 Not checking non-zero UDP checksums on inbound >> traffic (at the >>> ETR >>> in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6). >>> There is >>> concern that checking the checksums would cause two problems: >>> performance issues for existing routers that lacks the ability to >>> perform the checksum efficiently, and problems when the zero UDP >>> checksums themselves are corrupted en route (particularly by poorly >>> implemented NAT boxes). This issue could be addressed in one of two >>> ways: (1) require standards-compliant behavior in LISP ETRs, or >>> include >>> a normative reference to a standards-track RFC that updates RFC >>> 1122 and >>> RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums. >>> >>> #2: Not Checking Inbound Non-Zero Checksums not Universally >>> Implemented. >>> >>> There are TCP/IP stacks that do not have any way to turn off >>> checking of >>> non-zero UDP checksums on receipt. If this functionality can be >>> turned >>> off, it may not be possible to turn it off for LISP traffic only , >>> while >>> it remains enabled for other traffic. Also, the checksum may be >>> checked >>> in hardware before the software sees the packet. This >> issue could be >>> resolved by changing the text that indicates that LISP ETRs "MUST" >>> ignore >>> incoming UDP checksums to a "MAY". >>> >>> ----------- >>> >>> Sam Hartman suggested text, and Dino Farinacci responded: >>> >>> On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote: >>> >>> You'd need to word it as an ITR MAY send a zero >> checksum, an ETR >>> MUST accept a 0 checksum and MAY ignore the checksum completely. >>> >>> Anyone object to me putting this text in the -04 spec now? >>> >>> -- >>> Ticket URL: >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From darlewis@cisco.com Thu Aug 20 13:42:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05ADB3A6F70 for ; Thu, 20 Aug 2009 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSOl2bad9G8D for ; Thu, 20 Aug 2009 13:42:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 14DF43A6F6B for ; Thu, 20 Aug 2009 13:42:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADNSjUqrR7MV/2dsb2JhbAC/N4gvkRAFhBg X-IronPort-AV: E=Sophos;i="4.43,416,1246838400"; d="scan'208";a="197477504" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2009 20:42:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7KKgEMZ013840; Thu, 20 Aug 2009 13:42:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7KKgECD021297; Thu, 20 Aug 2009 20:42:14 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:42:14 -0700 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, 20 Aug 2009 13:42:11 -0700 Message-ID: In-Reply-To: <4A8DB3EC.8050908@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation Thread-Index: Acoh1f4OwZNJl1zQQ2S7OsYJrdEozwAAIqgA References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <4A8DB3EC.8050908@joelhalpern.com> From: "Darrel Lewis (darlewis)" To: "Joel M. Halpern" X-OriginalArrivalTime: 20 Aug 2009 20:42:14.0517 (UTC) FILETIME=[B31C3A50:01CA21D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1114; t=1250800934; x=1251664934; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20#7=3A=20LISP=20ETRs=20ignoring =20checksum=20value=20in=20LISP=20UDP=20outer=20header=20on= 20decapsulation |Sender:=20; bh=zJvMoGcJBHJM7wClpWAMfjjYdNX4MVW+nAvRKuZOU9M=; b=mQEItrO8LGmvO1QIy3IlRNQ8H0MzFBQxXyPYx1y3boQn1WmrV3DQHt6wbJ sD+JP/OTBfBtcQeIC0bWXwYfhbU91N6OH6kxEzeI+EYqci52I/d7CbpGx0hd 7wcwr6OFDqDPmXx7i4SBjkG/DADa1hJOvIBr4NuMVQRwrivRjI9gc=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 20:42:10 -0000 > This WG can do something different, but in most WGs that use=20 > trackers,=20 > "spec viewpoint" is not part of the base item. The problem=20 > statement is=20 > just that, the problem statement. Discussion is then included as=20 > separate items, typically because the tracker picks up the=20 > discussion as=20 > long as the tracker number is in the subject. >=20 > One of the points of this is to avoid biasing the entry=20 > either towards=20 > or away from any specific resolution. We all know that it=20 > works better=20 > to separate the problems from the solution. It also helps avoid=20 > defensiveness on the part of the author (or of the issue=20 > raiser) if they=20 > know that they are not expected or even allowed, to defend=20 > themselves.=20 > The existing text relative to an issue may be perfect. But the issue=20 > has been raised. It needs to be discussed and resolved. >=20 > Yours, > Joel >=20 Thanks Joel, and well taken. I can definitely see my ideas of what the tracker was tracking was out of step with the others in this thread. =20 -Darrel From jzwiebel@cisco.com Thu Aug 20 14:53:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A853A6C23 for ; Thu, 20 Aug 2009 14:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OG7XI6KIzlq for ; Thu, 20 Aug 2009 14:53:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DCD6C3A6C7C for ; Thu, 20 Aug 2009 14:53:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKFijUqrR7PE/2dsb2JhbACCVrwgiC+RBwWEGA X-IronPort-AV: E=Sophos;i="4.43,416,1246838400"; d="scan'208,217";a="197503403" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2009 21:53:47 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7KLrlJS005972; Thu, 20 Aug 2009 14:53:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7KLrlkJ019953; Thu, 20 Aug 2009 21:53:47 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 14:53:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA21E0.B1B2D220" Date: Thu, 20 Aug 2009 14:53:25 -0700 Message-ID: <1E1355AB5D71474AB186AE542E21AD1703695200@xmb-sjc-22c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Mobile LISP Thread-Index: AcohcHHnxRW2O8foRcahuKSGGheeiwAcDLiX References: <4A4E4724.5020207@joelhalpern.com> <9AE09228-7123-4759-BB6F-C5F43F3016CA@cisco.com> <4A4E6087.4090809@joelhalpern.com><53D1F202-326F-495C-8B84-70FAD92C604E@cisco.com><4A5C8E8B.1050305@gmail.com> <2B5F3EA7272CFF47A66518E4FF3BE23503B3CE5B@FIESEXC014.nsn-intra.net> <4A8C1C14.3030503@gmail.com> <1E1355AB5D71474AB186AE542E21AD17036951F7@xmb-sjc-22c.amer.cisco.com> <4A8D0994.5070901@gmail.com> From: "John Zwiebel (jzwiebel)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Aug 2009 21:53:47.0434 (UTC) FILETIME=[B1E360A0:01CA21E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1056; t=1250805227; x=1251669227; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20=22John=20Zwiebel=20(jzwiebel)=22=20 |Subject:=20RE=3A=20[lisp]=20Mobile=20LISP |Sender:=20; bh=9x0axq+ppc9qn0gqCdo8HlWp6JEWl/iaRFjtttN529c=; b=T3dfKDaW3QQ9D56Ilsb249DpZ8656YpIGyTlsHtRhc0X8kX/KM09p02jSy i+pKYi/RWhkwYGFijZOLlzihRD5t4jAOiBcVqa3lSjNTj1dXUw9iIfakwx5l +w42EggG8S; Authentication-Results: sj-dkim-4; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Mobile LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 20 Aug 2009 21:53:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA21E0.B1B2D220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John - but once the local RLOC is selected, thus allowing for direct=20 communication, there is always LISP encapsulation, right? Alex yes ------_=_NextPart_001_01CA21E0.B1B2D220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [lisp] Mobile LISP


John - but once the local RLOC is selected, thus = allowing for direct
communication, there is always LISP encapsulation, right?

Alex



<z> yes

------_=_NextPart_001_01CA21E0.B1B2D220-- From jnc@mercury.lcs.mit.edu Fri Aug 21 06:04:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A49D3A6E09 for ; Fri, 21 Aug 2009 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMTT8amifzmi for ; Fri, 21 Aug 2009 06:04:26 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 69FA03A67F2 for ; Fri, 21 Aug 2009 06:03:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 011A26BE5D1; Fri, 21 Aug 2009 09:03:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 09:03:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 13:04:27 -0000 > From: Margaret Wasserman > I do think it is important that we separate issues for that separate > questions that were raised. > ... > Because of all of this, I thought it would best to make these issues > explicitly separate. I don't have any opinion directly on the tracker items thing, but I would like to point out that some of these items are fairly inextricably connected on a _technical_ level. For example, iff _some_ ITRs are allowed to send packets with zero UDP checksums (i.e. 'MAY send zero checksums'), then either i) all ETRs MUST accept zero checksums, or ii) the specification allows configurations in which user traffic can vanish into a black hole. (I assume that everyone will concur that this latter behaviour is utterly unacceptable.) Noel From mrw@sandstorm.net Fri Aug 21 07:43:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CF028C1B1 for ; Fri, 21 Aug 2009 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ikKJPMlxdol for ; Fri, 21 Aug 2009 07:43:41 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3E12528C192 for ; Fri, 21 Aug 2009 07:43:41 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LEhTD9032054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 10:43:29 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <0CDB2DF8-C673-4B09-A5E7-5BDAC5BD0F54@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 10:43:29 -0400 References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 14:43:42 -0000 Hi Noel, On Aug 21, 2009, at 9:03 AM, Noel Chiappa wrote: > For example, iff _some_ ITRs are allowed to send packets with zero UDP > checksums (i.e. 'MAY send zero checksums'), then either i) all ETRs > MUST > accept zero checksums, or ii) the specification allows > configurations in > which user traffic can vanish into a black hole. (I assume that > everyone will > concur that this latter behaviour is utterly unacceptable.) I agee. If ITRs can send IPv6 UDP packets with zero checksums (meaning no checksum was calculated), then ETRs need to accept packets with zero checksums (without checking the checksum on receive). Those two do go together, and it would probably be worthwhile to update the issue about whether to allow this to reflect that. However, that isn't one of the lines on which my 7 issues were delineated... The issue about checksums on received UDP packets concerned the LISP spec's current wording that says that ETRs MUST ignore all UDP checksums, even non-zero ones, on receive, which is counter to current practice and to standards track RFCs for both IPv4 and IPv6. Ignoring _non-zero_ checksums on receive does not necessarily follow from allowing hosts to send zero checksums. Magaret From hartmans@mit.edu Fri Aug 21 08:05:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E54C3A6C66 for ; Fri, 21 Aug 2009 08:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH1SFZP2PSGF for ; Fri, 21 Aug 2009 08:05:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4C5D23A6831 for ; Fri, 21 Aug 2009 08:05:02 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9852B64492; Fri, 21 Aug 2009 11:05:06 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> From: Sam Hartman Date: Fri, 21 Aug 2009 11:05:06 -0400 In-Reply-To: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 21 Aug 2009 09\:03\:58 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:05:03 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Margaret Wasserman I do think it is >> important that we separate issues for that separate questions >> that were raised. ... Because of all of this, I thought it >> would best to make these issues explicitly separate. Noel> I don't have any opinion directly on the tracker items Noel> thing, but I would like to point out that some of these Noel> items are fairly inextricably connected on a _technical_ Noel> level. Noel> For example, iff _some_ ITRs are allowed to send packets Noel> with zero UDP checksums (i.e. 'MAY send zero checksums'), Noel> then either i) all ETRs MUST accept zero checksums, or ii) Noel> the specification allows configurations in which user Noel> traffic can vanish into a black hole. (I assume that Noel> everyone will concur that this latter behaviour is utterly Noel> unacceptable.) Unfortunately it seems completely unavoidable as well. * high-end routers seem unable to compute checksums efficiently in hardware * host stacks throw away bad UDP checksums in hardware; for V6, this often means throwing away 0 checksums Margaret and I have some experience with the second point. It was remarkably difficult to get lig working on some hosts--it was impossible to use the native UDP stack. (In our case the reason we were getting bad UDP checksums had to do with a problem on the other side. However I have very high confidence that you'd see the same problem implementing an ETR on that host.) We can definitely right self-consistent specs; I agree it would be unacceptable not to do so. However it seems that in practice, we will have significant problems with pairings that do not work, especially for IPV6. --Sam From jnc@mercury.lcs.mit.edu Fri Aug 21 08:14:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264CD3A6C39 for ; Fri, 21 Aug 2009 08:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-X7MKTn4AoQ for ; Fri, 21 Aug 2009 08:14:55 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8615B3A6AB5 for ; Fri, 21 Aug 2009 08:14:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 60C746BE5F3; Fri, 21 Aug 2009 11:14:45 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 11:14:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:14:56 -0000 > From: Margaret Wasserman >> then either i) all ETRs MUST accept zero checksums, or ii) the >> specification allows configurations in which user traffic can vanish >> into a black hole. (I assume that everyone will concur that this >> latter behaviour is utterly unacceptable.) > The issue about checksums on received UDP packets concerned the LISP > spec's current wording that says that ETRs MUST ignore all UDP > checksums, even non-zero ones, on receive ... Ignoring _non-zero_ > checksums on receive does not necessarily follow from allowing hosts to > send zero checksums. Actually, it does - but via an intermediate step through 'deployed base' issues. (I.e. a somewhat separate technical cause/rationale; one that goes along a different logic path than my prior example.) There are, it turns out, a lot of forwarding boxes already deployed out there that _wrongly_ update zero UDPv4 checksums in packets passing through them, so that a packet that sets out with a zero checksum will arrive with a non-zero checksum. (Which just goes to show that not much stuff is using the ability to send 0 checksum, as allowed by the UDP RFC, otherwise this would have shown up as a problem before now. But I digress...) Anyway, in this situation, iff _some_ ITRs are allowed to send packets with zero UDP checksums (i.e. 'MAY send zero checksums'), then either i) all ETRs MUST _ignore_ the UDP checksums, even (especially!) if non-zero, or ii) the specification will allow real-world configurations in which user traffic will vanish into a black hole. (Repeat prior comment.) But this is turning into a technical discussion about checksums, and I was merely wanting to point out that the various checksum questions do have some inextricable technical linkages. Noel From jnc@mercury.lcs.mit.edu Fri Aug 21 08:29:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8743A6DC3 for ; Fri, 21 Aug 2009 08:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsrSyw19EJbo for ; Fri, 21 Aug 2009 08:29:24 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E992E3A686E for ; Fri, 21 Aug 2009 08:28:54 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 335116BE5F3; Fri, 21 Aug 2009 11:29:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821152900.335116BE5F3@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 11:29:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:29:25 -0000 > From: Sam Hartman > Unfortunately it seems completely unavoidable as well. > * high-end routers seem unable to compute checksums efficiently in hardware > * host stacks throw away bad UDP checksums in hardware; for V6, this > often means throwing away 0 checksums > ... > However it seems that in practice, we will have significant problems > with pairings that do not work, especially for IPV6. Indeed. My impression is that there is probably _no_ set of UDP checksum choices which does not have _some_ problems. So we merely get to chose which problem(s) we will grind our teeth and accept... Noel From jnc@mercury.lcs.mit.edu Fri Aug 21 08:40:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB61228C1DA for ; Fri, 21 Aug 2009 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S593XlEA6sjl for ; Fri, 21 Aug 2009 08:40:56 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E2C6D28C1E1 for ; Fri, 21 Aug 2009 08:40:55 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2FFB16BE5F3; Fri, 21 Aug 2009 11:41:01 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821154101.2FFB16BE5F3@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 11:41:01 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:40:57 -0000 PS: > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) > My impression is that there is probably _no_ set of UDP checksum > choices which does not have _some_ problems. There is 'of course' a way 'around' all this, but it involves i) a lot more mechanism in LISP, ii) taking an extra hope when trying to get from an ITR which _can't_ generate a UDP checkum to an ETR which _can't_ accept a non-zero checksum , and iii) deploying an infrastructure of intermediary boxes. As such, I don't think it's appropriate for an experimental protocol - and in any event, then we'd need to have the 'is the cure worse than the disease' discussion. Noel From mrw@sandstorm.net Fri Aug 21 08:52:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5E03A6E3E for ; Fri, 21 Aug 2009 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meVzrAHA4NGA for ; Fri, 21 Aug 2009 08:52:47 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5D4893A6DDE for ; Fri, 21 Aug 2009 08:52:47 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LFqaXF035164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 11:52:36 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 11:52:36 -0400 References: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:52:48 -0000 Hi Noel, On Aug 21, 2009, at 11:14 AM, Noel Chiappa wrote: >> From: Margaret Wasserman > >>> then either i) all ETRs MUST accept zero checksums, or ii) the >>> specification allows configurations in which user traffic can vanish >>> into a black hole. (I assume that everyone will concur that this >>> latter behaviour is utterly unacceptable.) > >> The issue about checksums on received UDP packets concerned the LISP >> spec's current wording that says that ETRs MUST ignore all UDP >> checksums, even non-zero ones, on receive ... Ignoring _non-zero_ >> checksums on receive does not necessarily follow from allowing >> hosts to >> send zero checksums. > > Actually, it does - but via an intermediate step through 'deployed > base' > issues. (I.e. a somewhat separate technical cause/rationale; one > that goes > along a different logic path than my prior example.) I understand this argument, but I think of this as a separate question/ issue than the question of whether to allow the use of non-zero UDP checksums in IPv6. One major difference is that this is an issue for both IPv4 and IPv6. > > There are, it turns out, a lot of forwarding boxes already deployed > out there > that _wrongly_ update zero UDPv4 checksums in packets passing > through them, so > that a packet that sets out with a zero checksum will arrive with a > non-zero > checksum. (Which just goes to show that not much stuff is using the > ability to > send 0 checksum, as allowed by the UDP RFC, otherwise this would > have shown up > as a problem before now. But I digress...) Sadly, it also turns out that there is a large deployed base of systems on which it is impossible to turn off UDP checksum calculation on received packets. There is also a large deployed base of hardware and software that computes UDP checksums (on send and receive) that will calculate checksums on all UDP packets that are sent and discard received IPv6/UDP packets with zero checksums, as well as discarding all packets with invalid checksums. The open questions in my mind are: (1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT boxes that corrupt UDP zero checksums? (2) How important is it for LISP ITRs/ETRs to be implementable on widely-deployed hardware and common operating systems? Are there choices that will allow us to do both? Or do we need to choose? > Anyway, in this situation, iff _some_ ITRs are allowed to send > packets with > zero UDP checksums (i.e. 'MAY send zero checksums'), then either i) > all ETRs > MUST _ignore_ the UDP checksums, even (especially!) if non-zero, or > ii) the > specification will allow real-world configurations in which user > traffic will > vanish into a black hole. (Repeat prior comment.) If there are buggy NATs in the world that corrupt the packets that go through them, some of their packets will vanish into a black hole. This is just a fact. But, does LISP really need to work over them? More than it needs to be implementable on non-custom hardware and software systems? Personally, I would choose the flexibility to implement and deploy LISP on a wide variety of systems, including currently available Mac OS, Windows, Linux and FreeBSD systems (just to name my favorites), over the ability to run it through buggy NATs that corrupt packets. Because I don't really see why I'd want (in a real world situation, as opposed to a test network) to run my LISP ITR/ETR (which is a tunnel endpoint that decapsulates traffic from remote networks) _inside_ of my NAT/firewall perimeter. But, YMMV. > But this is turning into a technical discussion about checksums, and > I was > merely wanting to point out that the various checksum questions do > have some > inextricable technical linkages. I agree that there are linkages. I was asked (by you amongst others) to try to make a distinction between IETF process-related issues and technical issues. I was also asked to clarify the distinction I was making between (1) the decision to allow IPv6 UDP zero checksums (on send and receive), and (2) the decision to allow nodes to ignore non- zero UDP checksums in received packets. So, I tried to make those distinctions in the issue list that I submitted. The first item, zero IPv6 UDP checksums, is the topic covered by Marshall's 6man draft. As far as I know, no one has written a draft that proposes allowing the second item, ignoring all UDP checksums on receipt. Margaret From mrw@sandstorm.net Fri Aug 21 08:56:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DED028C1E3 for ; Fri, 21 Aug 2009 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tOa2MlVTGXa for ; Fri, 21 Aug 2009 08:56:16 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E82E33A6A9E for ; Fri, 21 Aug 2009 08:56:12 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LFuGiE035378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 11:56:16 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <06681C69-C552-4161-A9A0-8A9726B02CEE@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090821152900.335116BE5F3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 11:56:16 -0400 References: <20090821152900.335116BE5F3@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 15:56:17 -0000 On Aug 21, 2009, at 11:29 AM, Noel Chiappa wrote: >> From: Sam Hartman > >> Unfortunately it seems completely unavoidable as well. >> * high-end routers seem unable to compute checksums efficiently in >> hardware >> * host stacks throw away bad UDP checksums in hardware; for V6, this >> often means throwing away 0 checksums >> ... >> However it seems that in practice, we will have significant problems >> with pairings that do not work, especially for IPV6. > > Indeed. > > My impression is that there is probably _no_ set of UDP checksum > choices > which does not have _some_ problems. So we merely get to chose which > problem(s) we will grind our teeth and accept... True. There is also the (admittedly less likely) possibility that we will weigh all of the UDP checksum-related problems against the cost of using a non-UDP encapsulation (the LAG/ECMP problem), and decide that is preferable to move to a different encapsulation. Personally, I am not certain I know what the best choice would be, but I do think it is very important that we get all of the issues on the table as clearly as possible, so that the group can weigh the options and make a well- informed decision. Thanks for your help so far in doing just that. Margaret From mrw@sandstorm.net Fri Aug 21 09:01:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E35A28C21E for ; Fri, 21 Aug 2009 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oapp5kPKwkJo for ; Fri, 21 Aug 2009 09:01:51 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3EE2428C1CF for ; Fri, 21 Aug 2009 09:01:50 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LG1oNA035584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 12:01:50 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <14B9B227-9C71-46EA-932C-3E8CB84F0B63@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 12:01:50 -0400 References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 16:01:52 -0000 On Aug 21, 2009, at 11:05 AM, Sam Hartman wrote: > > Unfortunately it seems completely unavoidable as well. > > * high-end routers seem unable to compute checksums efficiently in > hardware I think that this would be better stated: some high-end routers exist today that are unable to compute checksums efficiently in hardware. I don't know that this is a inherent property of all high-end routers (now, or in the future), but we know that there are some that cannot do this efficiently today. Margaret From gjshep@gmail.com Fri Aug 21 09:10:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7009E3A6927 for ; Fri, 21 Aug 2009 09:10:22 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojk9wGtkdMJc for ; Fri, 21 Aug 2009 09:10:21 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id BC01E3A6359 for ; Fri, 21 Aug 2009 09:10:20 -0700 (PDT) Received: by vws34 with SMTP id 34so770174vws.31 for ; Fri, 21 Aug 2009 09:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iuL3luW/AjaqmOEIt0KnmRzZ+/w9GqF7saRh+KBy2+M=; b=vBGujVIO45MGjaQ6bWSSlMuLPYxMGqTXxQdBmEnmDoGOwlAHy8EntkB2AjjNVnDUJZ Ud3z35OcIg6xavsGwfqVqyX0zc767fxzVxDLOLIC3efprDTlLnPlV7FQ27iFEofYm8iT 7fPbREooid+eJYyWOtKp0qntUD5akGWG5ph20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=dya2H17z/fnR6LRmR06WO6zygvfRN64ljDf9egaPfRVL/7a7tYapaExzopp7HIbBbt nXmsT4PlFCGeafugCKrMG/2v4YcqKf+Rm8q3fQy6L81tGBE0VHXYhYnIcYsMAWRYT8Fr TelIbzeGWL7J25Lfp0tyNWVROqt+uro7mnf08= MIME-Version: 1.0 Received: by 10.229.32.148 with SMTP id c20mr241763qcd.52.1250871025584; Fri, 21 Aug 2009 09:10:25 -0700 (PDT) In-Reply-To: <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> References: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> Date: Fri, 21 Aug 2009 09:10:25 -0700 Message-ID: <38c19b540908210910t7050b4cah33f34b0be0882bf3@mail.gmail.com> From: Greg Shepherd To: Margaret Wasserman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com 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, 21 Aug 2009 16:10:22 -0000 On Fri, Aug 21, 2009 at 8:52 AM, Margaret Wasserman wrot= e: > > Hi Noel, > > On Aug 21, 2009, at 11:14 AM, Noel Chiappa wrote: > >>> From: Margaret Wasserman >> >>>> then either i) all ETRs MUST accept zero checksums, or ii) the >>>> specification allows configurations in which user traffic can vanish >>>> into a black hole. (I assume that everyone will concur that this >>>> latter behaviour is utterly unacceptable.) >> >>> The issue about checksums on received UDP packets concerned the LISP >>> spec's current wording that says that ETRs MUST ignore all UDP >>> checksums, even non-zero ones, on receive ... Ignoring _non-zero_ >>> checksums on receive does not necessarily follow from allowing hosts to >>> send zero checksums. >> >> Actually, it does - but via an intermediate step through 'deployed base' >> issues. (I.e. a somewhat separate technical cause/rationale; one that go= es >> along a different logic path than my prior example.) > > I understand this argument, but I think of this as a separate question/is= sue > than the question of whether to allow the use of non-zero UDP checksums i= n > IPv6. =A0One major difference is that this is an issue for both IPv4 and = IPv6. >> >> There are, it turns out, a lot of forwarding boxes already deployed out >> there >> that _wrongly_ update zero UDPv4 checksums in packets passing through >> them, so >> that a packet that sets out with a zero checksum will arrive with a >> non-zero >> checksum. (Which just goes to show that not much stuff is using the >> ability to >> send 0 checksum, as allowed by the UDP RFC, otherwise this would have >> shown up >> as a problem before now. But I digress...) > > Sadly, it also turns out that there is a large deployed base of systems o= n > which > it is impossible to turn off UDP checksum calculation on received packets= . > > There is also a large deployed base of hardware and software that compute= s > UDP checksums > (on send and receive) that will calculate checksums on all UDP packets th= at > are sent and > discard received IPv6/UDP packets with zero checksums, as well as discard= ing > all > packets with invalid checksums. > > The open questions in my mind are: > > (1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT bo= xes > that > corrupt UDP zero checksums? > > (2) How important is it for LISP ITRs/ETRs to be implementable on > widely-deployed > hardware and common operating systems? > > Are there choices that will allow us to do both? =A0Or do we need to choo= se? > >> Anyway, in this situation, iff _some_ ITRs are allowed to send packets >> with >> zero UDP checksums (i.e. 'MAY send zero checksums'), then either i) all >> ETRs >> MUST _ignore_ the UDP checksums, even (especially!) if non-zero, or ii) >> the >> specification will allow real-world configurations in which user traffic >> will >> vanish into a black hole. (Repeat prior comment.) > > If there are buggy NATs in the world that corrupt the packets that go > through them, > some of their packets will vanish into a black hole. =A0This is just a fa= ct. > > But, does LISP really need to work over them? =A0More than it needs to be > implementable > on non-custom hardware and software systems? > > Personally, I would choose the flexibility to implement and deploy LISP o= n a > wide variety of systems, including currently available =A0Mac OS, Windows= , > Linux and FreeBSD systems (just to name my favorites), I believe you're referring to deploying LISP specifically on end host systems, correct? There are routers currently running BSD and Linux which may not have the UDP checksum performed on a host NICs so I don't believe this is an OS issue at all, but a hardware platform issue. I just think we need to be clear here. > over the ability to > run it through buggy NATs that corrupt packets. =A0Because I don't really= see > why I'd want (in a real world situation, as opposed to a test network) to > run my LISP ITR/ETR (which is a tunnel endpoint that decapsulates traffic > from remote networks) _inside_ of my NAT/firewall perimeter. =A0But, YMMV= . I don't really see why I'd want my real-world LISP deployment to run on a end-host system. Greg >> But this is turning into a technical discussion about checksums, and I w= as >> merely wanting to point out that the various checksum questions do have >> some >> inextricable technical linkages. > > I agree that there are linkages. =A0I was asked (by you amongst others) t= o try > to make a distinction between IETF process-related issues and technical > issues. =A0I was also asked to clarify the distinction I was making betwe= en > (1) the decision to allow IPv6 UDP zero checksums (on send and receive), = and > (2) the decision to allow nodes to ignore non-zero UDP checksums in recei= ved > packets. =A0So, I tried to make those distinctions in the issue list that= I > submitted. =A0The first item, zero IPv6 UDP checksums, is the topic cover= ed by > Marshall's 6man draft. =A0As far as I know, no one has written a draft th= at > proposes allowing the second item, ignoring all UDP checksums on receipt. > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Fri Aug 21 09:16:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27F53A6DFB for ; Fri, 21 Aug 2009 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPCLsmY7nBrP for ; Fri, 21 Aug 2009 09:16:03 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6C1203A6359 for ; Fri, 21 Aug 2009 09:16:03 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 51A946BE5C8; Fri, 21 Aug 2009 12:16:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821161608.51A946BE5C8@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 12:16:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 16:16:04 -0000 > From: Margaret Wasserman >> So we merely get to chose which problem(s) we will grind our teeth and >> accept... > There is also the ... possibility that we will weigh all of the UDP > checksum-related problems against the cost of using a non-UDP > encapsulation .., and decide that is preferable to move to a different > encapsulation. Ah, that's just a choice of a different set of teeth-grinding-actuating problems... :-) Noel From mrw@sandstorm.net Fri Aug 21 09:54:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2733A6974 for ; Fri, 21 Aug 2009 09:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlPitp-fM2dK for ; Fri, 21 Aug 2009 09:54:36 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 020113A6A64 for ; Fri, 21 Aug 2009 09:54:31 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LGsMLl037556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 12:54:28 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <130C93A0-186A-415C-8975-B089C88DD21E@sandstorm.net> From: Margaret Wasserman To: gjshep@gmail.com In-Reply-To: <38c19b540908210910t7050b4cah33f34b0be0882bf3@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 12:54:22 -0400 References: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> <17D8503C-FFEB-4A16-BC44-0470979FBAAB@sandstorm.net> <38c19b540908210910t7050b4cah33f34b0be0882bf3@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 16:54:37 -0000 On Aug 21, 2009, at 12:10 PM, Greg Shepherd wrote: >> >> Personally, I would choose the flexibility to implement and deploy >> LISP on a >> wide variety of systems, including currently available Mac OS, >> Windows, >> Linux and FreeBSD systems (just to name my favorites), > > I believe you're referring to deploying LISP specifically on end host > systems, correct? There are routers currently running BSD and Linux > which may not have the UDP checksum performed on a host NICs so I > don't believe this is an OS issue at all, but a hardware platform > issue. I just think we need to be clear here. As far as I have been able to tell, it is not possible to turn off checking inbound, non-zero UDP checksums on any of these operating systems, even when UDP checksums are not offloaded to the NIC. I know that there are lots of routers that run BSD and Linux, which is exactly my point. If people want to update those routers to support LISP as specified in LISP -03, they would need to modify their OS TCP/ IP stack, so that it will not calculate inbound UDP checksums for LISP traffic to the ETR. This could be somewhat tricky, as the stack would still need to calculate inbound UDP checksums for other protocols, such as SNMP and TFTP, to avoid corruption of boot images and provisioning information. This is one of the reasons why I don't think that we should require LISP ITRs/ETRs to ignore non-zero UDP checksums on receipt. Margaret From jnc@mercury.lcs.mit.edu Fri Aug 21 10:05:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CBA28C131 for ; Fri, 21 Aug 2009 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqFhuoHpyAMe for ; Fri, 21 Aug 2009 10:05:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8816928C126 for ; Fri, 21 Aug 2009 10:05:46 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8319B6BE5C8; Fri, 21 Aug 2009 13:05:51 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821170551.8319B6BE5C8@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 13:05:51 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 17:05:47 -0000 > From: Margaret Wasserman > One major difference is that this is an issue for both IPv4 and IPv6. ?? The 'if you allow sending zero, you have to have a MUST for allowing zero on reception, otherwise black holes' issue holds for both v4 and v6 too, no? Yes, the details of the 'intermediate boxes bash checksums' issue are probably subtly different between v4 and v6 (since it's clearly _already_ a protocol violation in v4), but was that what you meant? > it also turns out that there is a large deployed base of systems on > which it is impossible to turn off UDP checksum calculation on received > packets. Indeed - hence my prior comment to Sam about 'choice of teeth-grinding'. Bad choices to the left of us, bad choices to the right... > Personally, I would choose the flexibility to implement and deploy > LISP on a wide variety of systems ... over the ability to run it > through buggy NATs that corrupt packets. In general, I tend to lean towards the 'boxes which can't do X cannot be xTRs' bad choices, because there at least, it's very visible, and you know right up front that you have a problem. In other words, you have _some_ control over the problem - it's right there in front of you, in a local device over which you have some influence. To me, preferring the choices which allow more boxes to be xTRS, but which also can cause random pairings of xTRs to fail, because the path between them _may_ contain devices which cause packets to vanish - something which the end-nodes have no control over (either the path, or what boxes are out there in the network) - is a more user-unfriendly approach. (That also makes me realize that my prior comment about 'there is a way around this, but it is painful' is only half-correct. We _can_ work around the problem of 'non-UDP-checksum ITR talking to UDP-checkum ETR', albeit at a certain level of complexity. The 'box on the path bashes a zero checksum' problem causes me to truly shudder with horror... although now that I think about it, one can work around that one too - test the path, and treat like non-UDP/UDP if failure... but then there are path changes, so the path characteristics will change over time.... oh, and even better, what do you do if there's a bad box on the path _to_ to the intermediary box from the non-UDP box - yuck.) > (1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT > boxes that corrupt UDP[v4] zero checksums? Well, you can probably just simplify that to 'How important is it for LISP to work through NAT boxes', because there seem to be a _lot_ of the non-compliant ones out there, and requiring their extermination from the Internet before LISP can work reliably seems like a 'boiling the ocean' solution. But maybe I'm wrong there - there are numerous web site that just won't work unless you have the latest and greatest Flash player, or whatever, loaded onto your machine... :-( Anyway, _iff_ requiring people to eliminate them (which is another choice) is unreasonable, it does seem to boil (sic) down to either i) we accept that LISP doesn't work through NAT boxes at all, or ii) we have to work around the buggy ones - option iii) 'sometimes it works, and sometimes it doesn't' is, I claim, really just another name for i), for the average user. > (2) How important is it for LISP ITRs/ETRs to be implementable on > widely-deployed hardware and common operating systems? > > Are there choices that will allow us to do both? Or do we need to > choose? Well, I can't think of any... as long as we are using UDP... but then we get back to _that_ question! :-) Interesting how we keep going in the same circles, isn't it? :-) Noel From jnc@mercury.lcs.mit.edu Fri Aug 21 10:09:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86AA3A6922 for ; Fri, 21 Aug 2009 10:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcL0mvdVdAP9 for ; Fri, 21 Aug 2009 10:09:53 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 077AC3A6BB2 for ; Fri, 21 Aug 2009 10:09:52 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 44B336BE5C8; Fri, 21 Aug 2009 13:09:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821170958.44B336BE5C8@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 13:09:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 17:09:53 -0000 > From: Margaret Wasserman > I don't really see why I'd want (in a real world situation, as opposed > to a test network) to run my LISP ITR/ETR (which is a tunnel endpoint > that decapsulates traffic from remote networks) _inside_ of my > NAT/firewall perimeter. Mobile hosts, for one. There are probably others, but I'm not good at that sort of coming up with useful applications on the fly (hey, I missed both multi-homing _and_ provider independence as reasons to do identity/location separation :-). Can anyone else come up with that kind of deployment scenario? How about 'small business wants PI addresses and their ISP is selling NATed IP service'? Noel From hartmans@mit.edu Fri Aug 21 11:29:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1ECF3A6E1E for ; Fri, 21 Aug 2009 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e8V7HXwsl2B for ; Fri, 21 Aug 2009 11:29:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) by core3.amsl.com (Postfix) with ESMTP id 2862F3A6B63 for ; Fri, 21 Aug 2009 11:29:38 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1DD964492; Fri, 21 Aug 2009 14:29:29 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> From: Sam Hartman Date: Fri, 21 Aug 2009 14:29:29 -0400 In-Reply-To: <20090821151445.60C746BE5F3@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 21 Aug 2009 11\:14\:45 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 18:29:40 -0000 >>>>> "Noel" == Noel Chiappa writes: Noel> Actually, it does - but via an intermediate step through Noel> 'deployed base' issues. (I.e. a somewhat separate technical Noel> cause/rationale; one that goes along a different logic path Noel> than my prior example.) Noel> There are, it turns out, a lot of forwarding boxes already Noel> deployed out there that _wrongly_ update zero UDPv4 Noel> checksums in packets passing through them, so that a packet Noel> that sets out with a zero checksum will arrive with a Noel> non-zero checksum What data if any do we have about how common these broken forwarding boxes are and to what extent we need to care about them? From mrw@sandstorm.net Fri Aug 21 11:38:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB99C28C250 for ; Fri, 21 Aug 2009 11:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h80yElxEkLw for ; Fri, 21 Aug 2009 11:38:28 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4456428C21A for ; Fri, 21 Aug 2009 11:38:28 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LIcOvo041823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 14:38:24 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <15855B01-3089-4BC7-A334-479B9EB9A2CD@sandstorm.net> From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090821170551.8319B6BE5C8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 14:38:24 -0400 References: <20090821170551.8319B6BE5C8@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 18:38:29 -0000 On Aug 21, 2009, at 1:05 PM, Noel Chiappa wrote: >> From: Margaret Wasserman > >> One major difference is that this is an issue for both IPv4 and IPv6. > > ?? The 'if you allow sending zero, you have to have a MUST for > allowing zero > on reception, otherwise black holes' issue holds for both v4 and v6 > too, no? Yes, although there is no need to say this about IPv4, as IPv4 stacks already treat zero checksums as "no checksum calculated". > To me, preferring the choices which allow more boxes to be xTRS, but > which > also can cause random pairings of xTRs to fail, because the path > between them > _may_ contain devices which cause packets to vanish - something > which the > end-nodes have no control over (either the path, or what boxes are > out there > in the network) - is a more user-unfriendly approach. Actually, the simplest way to make LISP (or any UDP-based protocol) work through NAT boxes that bash packet with zero checksums is to use non-zero checksums. The only reason we're talking about using zero checksums at all is because there are boxes on which we want to implement ITRs/ETRs that don't support them efficiently. >> (1) How important is it for LISP ITRs/ETRs to work through (buggy) >> NAT >> boxes that corrupt UDP[v4] zero checksums? > > Well, you can probably just simplify that to 'How important is it > for LISP to > work through NAT boxes', because there seem to be a _lot_ of the non- > compliant > ones out there, Boxes where the software can't be upgraded to fix this? > and requiring their extermination from the Internet before > LISP can work reliably seems like a 'boiling the ocean' solution. > > Anyway, _iff_ requiring people to eliminate them (which is another > choice) is > unreasonable, it does seem to boil (sic) down to either i) we accept > that > LISP doesn't work through NAT boxes at all, or ii) we have to work > around the > buggy ones - option iii) 'sometimes it works, and sometimes it > doesn't' is, I > claim, really just another name for i), for the average user. Hmmm... I get your point. On the one hand, it isn't possible for the IETF to write standards that work around every bug that people manage to introduce in their software... But, on the other hand, it doesn't do much good to write standards that won't work in the real world... Let's consider your reworded question, though... How important it it that LISP work through NAT boxes? There are a number of things about the current LISP protocol that won't work through NAT boxes. I have only just started experimenting with LISP myself, but already I know that LIG doesn't work through NAT boxes, because the response comes back from a different port than the port to which the request was sent. Also, LISP allows map replies to come from a different IP address than the address to which the request was sent. And AH doesn't work through NAT boxes, does it? So, if we _do_ consider it a requirement for LISP to work through NATs, I think we have quite a bit of work to do to make it so. Personally, I don't understand why working through NAT boxes is important enough to make these sorts of changes, so I would prefer to leave LISP more like it is, and just drop the "works through NAT" requirement. But, are there good reasons why LISP should work through NATs that I haven't considered? I understand that there may be reasons why we need this, and if the WG decides that it _is_ important for LISP to work with NATs, I'll help to identify what needs to change to make that work. What doesn't make sense to me, though, is to define a protocol that won't work through NATs while requiring that LISP xTRs ignore inbound UDP checksums, and thus making it harder to implement on most systems, supposedly so that LISP will work through buggy NATs.... > > >> (2) How important is it for LISP ITRs/ETRs to be implementable on >> widely-deployed hardware and common operating systems? >> >> Are there choices that will allow us to do both? Or do we need to >> choose? > > Well, I can't think of any... as long as we are using UDP... but > then we get > back to _that_ question! :-) > > Interesting how we keep going in the same circles, isn't it? :-) Yes. I keep hoping we'll find a way out that we hadn't noticed before! :-) Margaret From mrw@sandstorm.net Fri Aug 21 11:40:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468D13A698C for ; Fri, 21 Aug 2009 11:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjDYby2KyK-X for ; Fri, 21 Aug 2009 11:39:59 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 733803A67D9 for ; Fri, 21 Aug 2009 11:39:59 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7LIdxbS041854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2009 14:39:59 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Noel Chiappa In-Reply-To: <20090821170958.44B336BE5C8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 14:39:59 -0400 References: <20090821170958.44B336BE5C8@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 18:40:00 -0000 On Aug 21, 2009, at 1:09 PM, Noel Chiappa wrote: >> From: Margaret Wasserman > >> I don't really see why I'd want (in a real world situation, as >> opposed >> to a test network) to run my LISP ITR/ETR (which is a tunnel endpoint >> that decapsulates traffic from remote networks) _inside_ of my >> NAT/firewall perimeter. > > Mobile hosts, for one. Hmmm... Which becomes a reason why it is important to be able to run LISP on common desktop operating systems... and around and around it goes. :-) > > > How about 'small business wants PI addresses and their ISP is > selling NATed > IP service'? Good one. Margaret From jmh@joelhalpern.com Fri Aug 21 11:42:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8649D28C21A for ; Fri, 21 Aug 2009 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71S7of8IoqLy for ; Fri, 21 Aug 2009 11:42:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 478D728C190 for ; Fri, 21 Aug 2009 11:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2863B430296; Fri, 21 Aug 2009 11:42:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1C473430225; Fri, 21 Aug 2009 11:42:20 -0700 (PDT) Message-ID: <4A8EEA89.6020105@joelhalpern.com> Date: Fri, 21 Aug 2009 14:42:17 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Margaret Wasserman References: <20090821170551.8319B6BE5C8@mercury.lcs.mit.edu> <15855B01-3089-4BC7-A334-479B9EB9A2CD@sandstorm.net> In-Reply-To: <15855B01-3089-4BC7-A334-479B9EB9A2CD@sandstorm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 18:42:17 -0000 Procedural suggestion: It is perfectly reasonable to have two items where Item 1 suggests a change X Item 2 says "If you do 1, figure out what to do about this corollary." The existence of item 2 in the tracker helps one avoid losing track of the pieces. Using two items allows one to focus ones discussion. I am not all that fond of using trackers. But if we are going to use them, may I suggest we actually use them to enable divide-and-conquer. Thank you, Joel Margaret Wasserman wrote: > > On Aug 21, 2009, at 1:05 PM, Noel Chiappa wrote: > >>> From: Margaret Wasserman >> >>> One major difference is that this is an issue for both IPv4 and IPv6. >> >> ?? The 'if you allow sending zero, you have to have a MUST for >> allowing zero >> on reception, otherwise black holes' issue holds for both v4 and v6 >> too, no? > > Yes, although there is no need to say this about IPv4, as IPv4 stacks > already treat zero checksums as "no checksum calculated". > >> To me, preferring the choices which allow more boxes to be xTRS, but >> which >> also can cause random pairings of xTRs to fail, because the path >> between them >> _may_ contain devices which cause packets to vanish - something which the >> end-nodes have no control over (either the path, or what boxes are out >> there >> in the network) - is a more user-unfriendly approach. > > Actually, the simplest way to make LISP (or any UDP-based protocol) work > through NAT boxes that bash packet with zero checksums is to use > non-zero checksums. > > The only reason we're talking about using zero checksums at all is > because there are boxes on which we want to implement ITRs/ETRs that > don't support them efficiently. > >>> (1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT >>> boxes that corrupt UDP[v4] zero checksums? >> >> Well, you can probably just simplify that to 'How important is it for >> LISP to >> work through NAT boxes', because there seem to be a _lot_ of the >> non-compliant >> ones out there, > > Boxes where the software can't be upgraded to fix this? > >> and requiring their extermination from the Internet before >> LISP can work reliably seems like a 'boiling the ocean' solution. >> >> Anyway, _iff_ requiring people to eliminate them (which is another >> choice) is >> unreasonable, it does seem to boil (sic) down to either i) we accept that >> LISP doesn't work through NAT boxes at all, or ii) we have to work >> around the >> buggy ones - option iii) 'sometimes it works, and sometimes it >> doesn't' is, I >> claim, really just another name for i), for the average user. > > Hmmm... I get your point. On the one hand, it isn't possible for the > IETF to write standards that work around every bug that people manage to > introduce in their software... But, on the other hand, it doesn't do > much good to write standards that won't work in the real world... > > Let's consider your reworded question, though... How important it it > that LISP work through NAT boxes? > > There are a number of things about the current LISP protocol that won't > work through NAT boxes. I have only just started experimenting with > LISP myself, but already I know that LIG doesn't work through NAT boxes, > because the response comes back from a different port than the port to > which the request was sent. Also, LISP allows map replies to come from > a different IP address than the address to which the request was sent. > And AH doesn't work through NAT boxes, does it? > > So, if we _do_ consider it a requirement for LISP to work through NATs, > I think we have quite a bit of work to do to make it so. > > Personally, I don't understand why working through NAT boxes is > important enough to make these sorts of changes, so I would prefer to > leave LISP more like it is, and just drop the "works through NAT" > requirement. But, are there good reasons why LISP should work through > NATs that I haven't considered? I understand that there may be reasons > why we need this, and if the WG decides that it _is_ important for LISP > to work with NATs, I'll help to identify what needs to change to make > that work. > > What doesn't make sense to me, though, is to define a protocol that > won't work through NATs while requiring that LISP xTRs ignore inbound > UDP checksums, and thus making it harder to implement on most systems, > supposedly so that LISP will work through buggy NATs.... >> >> >>> (2) How important is it for LISP ITRs/ETRs to be implementable on >>> widely-deployed hardware and common operating systems? >>> >>> Are there choices that will allow us to do both? Or do we need to >>> choose? >> >> Well, I can't think of any... as long as we are using UDP... but then >> we get >> back to _that_ question! :-) >> >> Interesting how we keep going in the same circles, isn't it? :-) > > Yes. I keep hoping we'll find a way out that we hadn't noticed before! > :-) > > Margaret > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Fri Aug 21 12:09:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EEB3A69CA for ; Fri, 21 Aug 2009 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qwrSsbLIHMW for ; Fri, 21 Aug 2009 12:09:55 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id D13A63A6DBB for ; Fri, 21 Aug 2009 12:09:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6D6606BE5F3; Fri, 21 Aug 2009 15:09:38 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821190938.6D6606BE5F3@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 15:09:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 19:09:55 -0000 > From: Margaret Wasserman >> The 'if you allow sending zero, you have to have a MUST for allowing >> zero on reception, otherwise black holes' issue holds for both v4 and >> v6 too, no? > Yes, although there is no need to say this about IPv4, as IPv4 stacks > already treat zero checksums as "no checksum calculated". Perhaps I'm reading RFC-1122 wrong, but it does say, in "4.1.3.4 UDP Checksums": "An application MAY optionally be able to control whether UDP datagrams without checksums should be discarded or passed to the application." which I take to mean that one can build an 1122-compliant host which _does not_ provide to applications the option to accept UDPv4 datagrams without a checksum, but rather simply discards them. So it seems that one wouldn't be able to run LISP as an application in such boxes, and have it accept packets with zero checksums (since the OS would discard them first)? Or am I reading RFC-1122 incorrectly? Does anyone know of OS's which display this UDPv4 behaviour? Noel From dino@cisco.com Fri Aug 21 12:51:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475333A6B28 for ; Fri, 21 Aug 2009 12:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQiShc6MwfPj for ; Fri, 21 Aug 2009 12:51:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 668113A6A0F for ; Fri, 21 Aug 2009 12:51:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPyXjkqrR7PE/2dsb2JhbAC9OYg3kG0FhBqBVIhp X-IronPort-AV: E=Sophos;i="4.44,252,1249257600"; d="scan'208";a="197850957" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 21 Aug 2009 19:51:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7LJpeGo012222; Fri, 21 Aug 2009 12:51:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7LJpe7P011621; Fri, 21 Aug 2009 19:51:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:51:40 -0700 Received: from [192.168.1.3] ([10.21.72.27]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:51:39 -0700 Message-Id: <9D415964-E1E4-4E10-895D-FE399AD5AA18@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 12:51:39 -0700 References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 Aug 2009 19:51:39.0875 (UTC) FILETIME=[CCBC5B30:01CA2298] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=862; t=1250884300; x=1251748300; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20#7=3A=20LISP=20ETRs=20ignoring =20checksum=20value=20in=20LISP=20UDP=20outer=20header=20on= 20decapsulation |Sender:=20; bh=MPKG8DaZxvfOYaMoEWYARZDkkJb3K51sbuq1yp2heQY=; b=bAXrNLcd2IrMX2AwJaDvGvdErZxVK0xUD1+HwncubjD3U9etoBzLQ7pAYP wZqbn6ry9sNFtaN+KoQGkiN5XUi+b06Pmgl61yqyhviwMI4Ym96tMox+imed VMIeYCCC0F; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 19:51:35 -0000 > Margaret and I have some experience with the second point. It was > remarkably difficult to get lig working on some hosts--it was > impossible to use the native UDP stack. (In our case the reason we Lig uses Map-Requests and Map-Replies. Those are control packets which to use non-zero UDP checksums for both IPv4 and IPv6. Want to keep it clear from the UDP checksum discussion on zero UDP checksums *on data packets*. Dino > were getting bad UDP checksums had to do with a problem on the other > side. However I have very high confidence that you'd see the same > problem implementing an ETR on that host.) We can definitely right > self-consistent specs; I agree it would be unacceptable not to do so. > However it seems that in practice, we will have significant problems > with pairings that do not work, especially for IPV6. From hartmans@mit.edu Fri Aug 21 13:01:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180EF3A6B63 for ; Fri, 21 Aug 2009 13:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziTs5sx6Fuao for ; Fri, 21 Aug 2009 13:01:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) by core3.amsl.com (Postfix) with ESMTP id 82B3E3A6AA3 for ; Fri, 21 Aug 2009 13:01:23 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 817096461A; Fri, 21 Aug 2009 16:01:18 -0400 (EDT) To: Dino Farinacci References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> <9D415964-E1E4-4E10-895D-FE399AD5AA18@cisco.com> From: Sam Hartman Date: Fri, 21 Aug 2009 16:01:18 -0400 In-Reply-To: <9D415964-E1E4-4E10-895D-FE399AD5AA18@cisco.com> (Dino Farinacci's message of "Fri\, 21 Aug 2009 12\:51\:39 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 20:01:27 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Margaret and I have some experience with the second point. It >> was remarkably difficult to get lig working on some hosts--it >> was impossible to use the native UDP stack. (In our case the >> reason we Dino> Lig uses Map-Requests and Map-Replies. Those are control Dino> packets which to use non-zero UDP checksums for both IPv4 Dino> and IPv6. Agreed. I was trying to focus on something we learned while looking at lig--turning off checksum verification is hard on a number of stacks. You're right that it didn't matter much that I was using lig and bringing that up might have confused people. From dino@cisco.com Fri Aug 21 13:31:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1F93A6872 for ; Fri, 21 Aug 2009 13:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0HbaakHJlJV for ; Fri, 21 Aug 2009 13:31:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4956C3A69EE for ; Fri, 21 Aug 2009 13:31:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOOgjkqrR7MV/2dsb2JhbAC9T4g3kGcFhBqBVIhp X-IronPort-AV: E=Sophos;i="4.44,252,1249257600"; d="scan'208";a="185043078" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Aug 2009 20:31:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7LKVMY9018885; Fri, 21 Aug 2009 13:31:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7LKVLXR002431; Fri, 21 Aug 2009 20:31:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 13:31:21 -0700 Received: from [192.168.1.3] ([10.21.151.167]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 13:31:21 -0700 Message-Id: <4E688639-5982-4D59-8FBE-5B72552C3F0E@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 21 Aug 2009 13:20:02 -0700 References: <20090821130359.011A26BE5D1@mercury.lcs.mit.edu> <9D415964-E1E4-4E10-895D-FE399AD5AA18@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 Aug 2009 20:31:21.0546 (UTC) FILETIME=[585282A0:01CA229E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=784; t=1250886682; x=1251750682; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20#7=3A=20LISP=20ETRs=20ignoring =20checksum=20value=20in=20LISP=20UDP=20outer=20=20header=20 on=20decapsulation |Sender:=20; bh=EIssJ7nBUBKOdW3Rugaxkt5MeGBbngjkzU98r8HpHSI=; b=p61N3u9m7U2pASblfEqqWGeODuGbeBQJsWGggyI0PQte9uimVHHifdH62V g7gETPP4vmCIOJrprS8YMxHCfJ4ytOWlr8wm7YFjUWbivutLlCF46le2cgHA QuHrZeeo/3jPKG9gb1Re1Ns2fLwFCEAdTTh+Dxf9YRUaRLwo1ONO0=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 20:31:17 -0000 Ack, gotcha. Dino On Aug 21, 2009, at 1:01 PM, Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > >>> Margaret and I have some experience with the second point. It >>> was remarkably difficult to get lig working on some hosts--it >>> was impossible to use the native UDP stack. (In our case the >>> reason we > > Dino> Lig uses Map-Requests and Map-Replies. Those are control > Dino> packets which to use non-zero UDP checksums for both IPv4 > Dino> and IPv6. > > Agreed. I was trying to focus on something we learned while looking > at lig--turning off checksum verification is hard on a number of > stacks. You're right that it didn't matter much that I was using lig > and bringing that up might have confused people. From jnc@mercury.lcs.mit.edu Fri Aug 21 13:31:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767123A6B63 for ; Fri, 21 Aug 2009 13:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tttaRqNecDyU for ; Fri, 21 Aug 2009 13:31:22 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A0A013A6845 for ; Fri, 21 Aug 2009 13:31:22 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 778BC6BE557; Fri, 21 Aug 2009 16:31:27 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821203127.778BC6BE557@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 16:31:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 20:31:23 -0000 > From: Margaret Wasserman > Boxes where the software can't be upgraded to fix this? I dunno about that. The real issue would be if those intermediate boxes are something the LISP-user has no control over... > On the one hand, it isn't possible for the IETF to write standards that > work around every bug that people manage to introduce in their > software... But, on the other hand, it doesn't do much good to write > standards that won't work in the real world... Exactly... very concisely put! > How important it it that LISP work through NAT boxes? The $64M question - probably best to answer that first, because a lot of the other questions depend on the answer to that one. > So, if we _do_ consider it a requirement for LISP to work through NATs, > I think we have quite a bit of work to do to make it so. Dunno - I just don't recall off the top of my head how far people have already gotten with through-NAT operation (see next message). > What doesn't make sense to me, though, is to define a protocol that > won't work through NATs while requiring that LISP xTRs ignore inbound > UDP checksums, and thus making it harder to implement on most systems, > supposedly so that LISP will work through buggy NATs.... Yes, that's a good point. >> Interesting how we keep going in the same circles, isn't it? :-) > I keep hoping we'll find a way out that we hadn't noticed before! :-) ROTFL! Although every so often, I do notice something new (e.g. the bit about how it would be possible to create a mechanism to allow interoperation between no-UDP-checksum ITRs and no-UDP-checksum-ignore ETRs - maybe we will add that in the future). > Hmmm... Which becomes a reason why it is important to be able to run > LISP on common desktop operating systems... and around and around it > goes. :-) :-) Well, at least we're all getting a good chuckle out of it on _this_ turn around the wheel... :-) Noel From jnc@mercury.lcs.mit.edu Fri Aug 21 14:18:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE793A6BB7 for ; Fri, 21 Aug 2009 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq-CVv15+tXi for ; Fri, 21 Aug 2009 14:18:14 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id BD5D23A6ABB for ; Fri, 21 Aug 2009 14:18:14 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7C6006BE557; Fri, 21 Aug 2009 17:18:19 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821211819.7C6006BE557@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 17:18:19 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 21:18:15 -0000 [Separate sub-thread about working through NAT boxes - not sure how much I can change the Subject line and have the tracker keep track of things...] > From: Margaret Wasserman > There are a number of things about the current LISP protocol that won't > work through NAT boxes. I'm not really the expert on the details of LISP working through NAT boxes, so here I'll have to call on others for help. I do think it has been tried, or am I mis-remembering what I heard? I do know there's been a fair amount of attention given to operation behind a NAT. In any event, I think you've identified an excellent general point: if we intend to have LISP work through NAT boxes, we need to survey LISP, and make sure there no stuff that won't work there, and fix any problems we do find. > I know that LIG doesn't work through NAT boxes, because the response > comes back from a different port than the port to which the request was > sent. I seem to recall Dave Meyer having a very similar problem to this, but his was different (something about Unix and UDP ports). > Also, LISP allows map replies to come from a different IP address than > the address to which the request was sent. That is likely something of an issue... If so, there are, I think, relatively easy fixes for this, although they introduce a slight amount of inefficiency - the Map-Reply just has to come via the Map-Resolver (blasted name - I keep thinking the 'Map-Server' is what the users talk to, but of course it is a different function :-). And of course the LISP box has to 'know' that it's behind a NAT box, but IIRC someone clever (Darrell?) has already worked out a way to do that, and figure out what its 'outside' address is. Now that I mention that, I have this vague memory that the different IP address issue was sorted as well, but that could be wrong. > And AH doesn't work through NAT boxes, does it? Depends on the type of authentication, if memory serves (i.e. all the ones that cover the address fail). Surely someone has defined a type of IP authentication that works through a NAT box by now, though? The blasted things are ubiquitous... Noel From jnc@mercury.lcs.mit.edu Fri Aug 21 14:20:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294CF3A69E1 for ; Fri, 21 Aug 2009 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApdbdrDKTMzG for ; Fri, 21 Aug 2009 14:20:05 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 703FF3A6831 for ; Fri, 21 Aug 2009 14:20:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D4A9E6BE557; Fri, 21 Aug 2009 17:20:09 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821212009.D4A9E6BE557@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 17:20:09 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 21:20:06 -0000 > From: Sam Hartman > What data if any do we have about how common these broken forwarding > boxes are and to what extent we need to c are about them? There was this message a few days back: >> From: "Darrel Lewis (darlewis)" >> Subject: RE: [lisp] Judging Consensus on the UDP Checksum Issue >> Date: Tue, 11 Aug 2009 10:25:56 -0700 >> Message-ID: >>> I would expect a NAT that saw a zero value to not recalculate the checksum. >> We found this not to be the case in our testing of LISP. Many >> commercial (netgear and linksys being two that come to mind) NATs do >> indeed recalculate the checksum regardless of its initial value. Needless to say, these are both very, very common boxes. Not sure if all models have this problem, or just some... Noel From darlewis@cisco.com Fri Aug 21 14:26:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324783A6B68 for ; Fri, 21 Aug 2009 14:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4mMG+DbpXZP for ; Fri, 21 Aug 2009 14:26:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4CBE53A6A8A for ; Fri, 21 Aug 2009 14:26:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIutjkqrR7MV/2dsb2JhbAC9QIg3kFkFhBqBVIhp X-IronPort-AV: E=Sophos;i="4.44,252,1249257600"; d="scan'208";a="372571645" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Aug 2009 21:26:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7LLQKCq009925; Fri, 21 Aug 2009 14:26:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7LLQKwl019072; Fri, 21 Aug 2009 21:26:20 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 14:26:19 -0700 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: Fri, 21 Aug 2009 14:26:19 -0700 Message-ID: In-Reply-To: <20090821212009.D4A9E6BE557@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation Thread-Index: AcoipSx01YKBd+SGRCyF/4EJZNbglgAALCxQ References: <20090821212009.D4A9E6BE557@mercury.lcs.mit.edu> From: "Darrel Lewis (darlewis)" To: "Noel Chiappa" , X-OriginalArrivalTime: 21 Aug 2009 21:26:19.0932 (UTC) FILETIME=[065045C0:01CA22A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=947; t=1250889980; x=1251753980; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20#7=3A=20LISP=20ETRs=20ignoring =20checksum=20value=20in=20LISP=20UDP=20outerheader=20on=20d ecapsulation |Sender:=20; bh=gjm8NomUH4X3zZ4hUQJgQSUaeHSgowRd0hJE4SLCucI=; b=QN+De+QTjsSaJei9CIigmaXGG1shAxR8xn1gNpvhUxbMCY8BusnRteAx/8 ObPe4HRE8VyG0P9OJ5WHKeppX619s76ya6OlsQiyTTiN/SQwXEIj4DQOUR6x RC52+7mbCskGUX+ob2IGAH86XmCLSMBmPajoYx2LqQoRGQZe3mVsE=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 21:26:15 -0000 =20 > >> From: "Darrel Lewis (darlewis)" > >> Subject: RE: [lisp] Judging Consensus on the UDP Checksum Issue > >> Date: Tue, 11 Aug 2009 10:25:56 -0700 > >> Message-ID:=20 > >=20 > >>> I would expect a NAT that saw a zero value to not=20 > recalculate the checksum. >=20 > >> We found this not to be the case in our testing of LISP. Many > >> commercial (netgear and linksys being two that come to=20 > mind) NATs do > >> indeed recalculate the checksum regardless of its=20 > initial value. >=20 > Needless to say, these are both very, very common boxes. Not=20 > sure if all models > have this problem, or just some... >=20 Noel, I want to be clear above, the IPv4 packet's checksum is changed from 0 to a non-zero (but correct) value on the NAT'd packet. Sorry if this was unclear. -Darrel From jnc@mercury.lcs.mit.edu Fri Aug 21 14:54:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAB93A6B5A for ; Fri, 21 Aug 2009 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0v75iWL+bgr for ; Fri, 21 Aug 2009 14:54:30 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C8D6A3A6C61 for ; Fri, 21 Aug 2009 14:54:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8941C6BE557; Fri, 21 Aug 2009 17:54:31 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090821215431.8941C6BE557@mercury.lcs.mit.edu> Date: Fri, 21 Aug 2009 17:54:31 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Aug 2009 21:54:31 -0000 > From: "Darrel Lewis (darlewis)" > the IPv4 packet's checksum It take it you mean the UDPv4 checksum, not the IPv4 header checksum, right? > is changed from 0 to a non-zero (but correct) value on the NAT'd > packet. ^^^^^^^^^^^ Oh! Big (and _important_) difference! :-) That makes our life significantly simpler. (Yah! :-) I just (naturally - see below) assumed that what they were doing was updating the UDP checksum, assuming it was already correct, without bothering to check to see if it was zero. Sorry, should have read your note more carefully! The following is something of an aside, but.. _Calcalating_ the correct checksum when it's zero is... somewhat bizarre - and, I would argue, incorrect behaviour. For one, it makes the recipient think the data can be relied upon - but it can't, because it might have been damaged _before_ it got to the NAT box. (Depending on exactly _what_ they are doing, they might even be causing a problem, on non-zero-checksum packets. E.g. if they always recalculate the checksum on outgoing packets, then iff the packet had a bit-error _while it was sitting in the NAT's buffer memory_, they have now created a damaged packet with a 'correct' checksum. The checksums are _supposed_ to be _end-to-end_ for a reason!) For another, it might cause the recipient to expend cycles calculating the checksum to make sure it's right, instead of just blowing past it. (Will that be an issue for LISP?) Finally, if applications are setting the checksum to zero, it's because they have some use for damaged packets - only now, damaged packets will likely (depending on the OS) be tossed due to bad checksums, rather than being given to the application anyway. Noel From hartmans@mit.edu Fri Aug 21 18:20:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED8C3A69B5 for ; Fri, 21 Aug 2009 18:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+xWjvKJJjgN for ; Fri, 21 Aug 2009 18:20:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E3EB63A6963 for ; Fri, 21 Aug 2009 18:20:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C63664631; Fri, 21 Aug 2009 21:20:33 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090821211819.7C6006BE557@mercury.lcs.mit.edu> From: Sam Hartman Date: Fri, 21 Aug 2009 21:20:33 -0400 In-Reply-To: <20090821211819.7C6006BE557@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 21 Aug 2009 17\:18\:19 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 01:20:30 -0000 >>>>> "Noel" == Noel Chiappa writes: Noel> Surely someone has defined a type of IP authentication that Noel> works through a NAT box by now, though? The blasted things Noel> are ubiquitous... Sure. IPsec esp-null with NAT traversal. or ip over TLS (I don't recommend this for us, but it's in wide use). If we do want to do our map-register authentication based on IPsec, we can probably make that work. From hartmans@mit.edu Fri Aug 21 18:48:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1373A6B9D for ; Fri, 21 Aug 2009 18:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXq42ZL3G3Dl for ; Fri, 21 Aug 2009 18:48:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 83B563A6862 for ; Fri, 21 Aug 2009 18:48:15 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6499964631; Fri, 21 Aug 2009 21:48:20 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <4A8DB3EC.8050908@joelhalpern.com> From: Sam Hartman Date: Fri, 21 Aug 2009 21:48:20 -0400 In-Reply-To: (Darrel Lewis's message of "Thu\, 20 Aug 2009 13\:42\:11 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 01:48:16 -0000 >>>>> "Darrel" == Darrel Lewis (darlewis) writes: Thanks Joel, and well taken. I can definitely see my ideas of what the Darrel> tracker was tracking was out of step with the others in Darrel> this thread. I actually think you are more or less completely in step with what we eventually want to get into the tracker by the time we close an issue. I appreciate you were trying to do that. However I think what we're saying here is that it is far more important to get things written down soon than to try and get a complete record in the beginning. Also, people get upset when they perceive bias--and right now, we're all a bit trigger happy on the issue of bias. --Sam From hartmans@mit.edu Sat Aug 22 03:40:14 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88A73A6B8C for ; Sat, 22 Aug 2009 03:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-kI1MdQoWEq for ; Sat, 22 Aug 2009 03:40:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 171FB3A6801 for ; Sat, 22 Aug 2009 03:40:13 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7C5C64631; Sat, 22 Aug 2009 06:40:16 -0400 (EDT) To: Sam Hartman References: <057.c1c8ee4f9843d34a996bf6dc5b557ba7@tools.ietf.org> <8DB4BB92-47A1-45BE-9735-528B64AF594F@sandstorm.net> <4A8DB3EC.8050908@joelhalpern.com> From: Sam Hartman Date: Sat, 22 Aug 2009 06:40:16 -0400 In-Reply-To: (Sam Hartman's message of "Fri\, 21 Aug 2009 21\:48\:20 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Margaret Wasserman Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 10:40:15 -0000 >>>>> "Sam" == Sam Hartman writes: >>>>> "Darrel" == Darrel Lewis (darlewis) writes: Sam> Thanks Joel, and well taken. I can definitely see my ideas Sam> of what the Darrel> tracker was tracking was out of step with the others in Darrel> this thread. Sam> I actually think you are more or less completely in step with Sam> what we eventually want to get into the tracker by the time Sam> we close an issue. I appreciate you were trying to do that. Sam> However I think what we're saying here is that it is far more Sam> important to get things written down soon than to try and get Sam> a complete record in the beginning. Also, people get upset Sam> when they perceive bias--and right now, we're all a bit Sam> trigger happy on the issue of bias. It was pointed out to me off-list that I was misleading above. The description of the issue should not contain more than what is wrong in the opinion of the person raising the issue along with any suggestions for fixing it raised by that person. It's reasonable to add context so others can understand what they were saying--context from surrounding messages, or for example if putting in an issue based on discussion at a meeting, context about what was being discussed. This context doesn't need to include motivations, typically doesn't need to include text from the draft beyond what the pe.person already included. However, by the time we close an issue it's often very desirable for the ticket as a whole to include some or all of the following: * Pointes of view raised in the discussion * Explanations of what motivated the previous text in the opinion of WG participants * The resolution of the issue These will typically be in separate comments in the tracker, or in a summary message prepared by the chairs. Hope that helps. From hartmans@mit.edu Sat Aug 22 04:06:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E013A6986 for ; Sat, 22 Aug 2009 04:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E86lqHW4zM2 for ; Sat, 22 Aug 2009 04:06:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id EC0F73A689D for ; Sat, 22 Aug 2009 04:06:52 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E3FCD64631; Sat, 22 Aug 2009 07:06:56 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Sat, 22 Aug 2009 07:06:56 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Discussing LISP deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 11:06:53 -0000 Folks, both as a chair and individual participant I'm finding that my lack of understanding of how LISP is being deployed is making it impossible for me to reason about most if not all of the issues we're discussing or that I'd like to bring up. I don't think we're 100% wedged on the UDP checksum issue based on understanding deployment, although I do expect I won't be able to make any final consensus call without understanding where LISP will be deployed. For most everything else, I am even more dependent on understanding deployment. Darrel and I are trying to organize a discussion on this but are blocked on getting some input from the ADs about IETF procedures. I just wanted to let the WG know that I at least think this is going to be a really important discussion and may block our work. Here are examples of the sorts of questions I cannot answer. Please don't try to answer these one-at-a-time. I think we really need an organized discussion of how the entire thing all fits together; I'm listing these as things I want to learn by the end, not as things that I think can be answered separately. * Why does LISP need to work through NATs * Why does LISP need to run on high-end routers at sufficient speed that hardware concerns matter? * Why does LISP need to run on low-end CPEs/home gateways? * Where are the organizational boundaries between a MS and its clients * Where are the organizational boundaries between the MR and its clients * How far down the scale should LISP expect to be deployed? Homes? 1-person businesses? 50? 100? * How far up the scale should LISP expect to be deployed? * How does an XTR get RLOC-side connectivity ** link type ** provisioning ** Does the ISP know LISP is being used? Go along with it? * Where does LISP run? CPE? PE? P? C? * How much do we care about LISP over V4? V6? Again, I don't think answering those questions singly would help. Clearly we could say that LISP needs to run everywhere in the network, on all equipment, from my house up through IBM and Oracle, for V4 and V6, supporting everything from RFC 1149 through multiple 10G links in a LAG. However if we say that, we'll produce bad results because evaluating tradeoffs will be impossible. I also fully realize that we'll probably not answer some of the questions I asked and have incomplete answers for others. Finally, I realize that real-world deployment will take its own path. What I'm trying to do is get our operating assumptions about deployment so we can make hard choices in the sort of sticky situations we find ourselves in with UDP. It's my opinion that what we have in the specs right now has an implied deployment model that is not self-consistent. The tradeoffs that are being made don't seem to fit together consistently. However rather than point out what I think are inconsistencies I'd rather learn from the people who wrote that document what they were thinking and then toss that around in a energetic but productive discussion until we get what the WG is thinking out. Then go back and make sure the spec aligns with the WG. From dino@cisco.com Sat Aug 22 09:53:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E2B3A6968 for ; Sat, 22 Aug 2009 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFMDvmPREY7g for ; Sat, 22 Aug 2009 09:53:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3269D3A6B3D for ; Sat, 22 Aug 2009 09:53:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMO/j0qrR7MV/2dsb2JhbAC6Sog3j3UFgjiBYoFWiHM X-IronPort-AV: E=Sophos;i="4.44,257,1249257600"; d="scan'208";a="373007385" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2009 16:53:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7MGrUkX009923; Sat, 22 Aug 2009 09:53:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7MGrU1Q015111; Sat, 22 Aug 2009 16:53:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 09:53:29 -0700 Received: from [192.168.1.5] ([10.21.146.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 09:53:29 -0700 Message-Id: <0F603AB5-B26F-4074-93FE-496A7C32DDBD@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 22 Aug 2009 09:53:29 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 22 Aug 2009 16:53:29.0313 (UTC) FILETIME=[1313CD10:01CA2349] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2682; t=1250960010; x=1251824010; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Discussing=20LISP=20deployment |Sender:=20; bh=MK3owzjBxS/gwVijXBA6Q4GveIacu6C2Pk1EmImYOts=; b=flZgWwXYhn9gpk9jS9yzD711H4qw8n7y//gFVaEZbWK5HRs6UNheWaXu7i 5p1JkbhKeBHcPyQSP0zQRVBctGpUoBBmTFN8GsvNpVEZZjmWFXdrXwZC94Ra Zt7foA+WhFbb4xXpMdfXyNyF0sdjahb7w/hkCgukKJ+UqCg9keYAo=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Discussing LISP deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 16:53:25 -0000 I am going to answer them briefly one by one because the answers are very simple. > * Why does LISP need to work through NATs Because you want to multi-home at a residence of a branch office which uses private addresses. > * Why does LISP need to run on high-end routers at sufficient speed > that hardware concerns matter? Because a LISP site can be a data center with lots of high-bandwidth connectivity to the core network. > * Why does LISP need to run on low-end CPEs/home gateways? Same answer for the first questions. > * Where are the organizational boundaries between a MS and its clients We don't know yet, but the architecture is flexible enough to put it anywhere. Can be third-party, government, SPs, IXCs, clouds, cachers, DNS root server vendors, etc. > * Where are the organizational boundaries between the MR and its > clients Same as last answer but can be modeled similar to the DNS hierarchy. > * How far down the scale should LISP expect to be deployed? Homes? > 1-person businesses? 50? 100? Where low-cost multi-homing is desirable. I run it at my house and enjoy active-active multi-homing both for ingress and egress traffic flow. > * How far up the scale should LISP expect to be deployed? I don't understand the question. Can be interpreted many ways so I don't want to guess what you are asking. > * How does an XTR get RLOC-side connectivity The same way a CPE router does today. > ** link type > ** provisioning > ** Does the ISP know LISP is being used? Go along with it? No, unless it is providing/selling mapping services to the site. Or offering PTR services for its customers. > * Where does LISP run? CPE? PE? P? C? CPE for loc/id split reasons. But inter-domain TE is important among SPs so other level of LISP could be run. That is an ISP could deploy TE-ITRs and TE-ETRs. These would likely be P routers or routers that are used at peering points between SPs. > * How much do we care about LISP over V4? V6? Since the host stacks have good IPv6 support, I envision we could deploy IPv6 by using LISP at sites with IPv6 EIDs and have sites reachable via IPv4 locators. So v6-in-v4 would make this work. And sine we what to scale the IPv4 Internet as we know it today, v4-in- v4 will obviously have to be supported. Using IPv6 as an outer header depends on native IPv6 intermediate connectivity. I just say though, we have done a lot of work to make IPv6 work on the LISP test network. So it's not an either or sort of situation. LISP is helping both address-families routing architecture scale. Dino From hartmans@mit.edu Sat Aug 22 11:02:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E803A6B1E for ; Sat, 22 Aug 2009 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6Z1BQ7nEgQx for ; Sat, 22 Aug 2009 11:02:50 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C9D763A6B14 for ; Sat, 22 Aug 2009 11:02:50 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3F70464631; Sat, 22 Aug 2009 14:02:53 -0400 (EDT) To: Dino Farinacci References: <0F603AB5-B26F-4074-93FE-496A7C32DDBD@cisco.com> From: Sam Hartman Date: Sat, 22 Aug 2009 14:02:53 -0400 In-Reply-To: <0F603AB5-B26F-4074-93FE-496A7C32DDBD@cisco.com> (Dino Farinacci's message of "Sat\, 22 Aug 2009 09\:53\:29 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Discussing LISP deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 18:02:51 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> I am going to answer them briefly one by one because the Dino> answers are very simple. Dino, thanks for trying. Your answers were not as simple as you thought they were: they were neither obviously correct nor sufficiently clear that I understood them. I could probably engage in a rapid fire discussion that would leave us both frustrated, but I think it would be better to wait until we can discuss something more organized. I do appreciate the response though. Speaking only for myself; I'm definitely not trying to discourage others from discussing. From dino@cisco.com Sat Aug 22 11:11:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7293A6B57 for ; Sat, 22 Aug 2009 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ+PVFwHhf4t for ; Sat, 22 Aug 2009 11:11:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 307A33A6B14 for ; Sat, 22 Aug 2009 11:11:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAzSj0qrR7PD/2dsb2JhbAC6N4g3j2cFhBqKSQ X-IronPort-AV: E=Sophos;i="4.44,257,1249257600"; d="scan'208";a="231643046" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2009 18:11:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7MIBgqQ031323; Sat, 22 Aug 2009 11:11:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7MIBg3g008413; Sat, 22 Aug 2009 18:11:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 11:11:42 -0700 Received: from [192.168.1.5] ([10.21.146.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Aug 2009 11:11:41 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 22 Aug 2009 11:11:41 -0700 References: <0F603AB5-B26F-4074-93FE-496A7C32DDBD@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 22 Aug 2009 18:11:41.0739 (UTC) FILETIME=[FFFB2FB0:01CA2353] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=711; t=1250964702; x=1251828702; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Discussing=20LISP=20deployment |Sender:=20; bh=Tv7SiqwRNdLmcjnrPsYBvH2ZyfjYHAJ0oWWuqhI1gdg=; b=DE5If/bSnNwtE3XaFncekCy6WZcGTPjgaZKm0QwB+Q1zJqaec2Zt77Ipm1 ELVjAYvywqVXmCEG1LZ+WvhoicodMCpklChzOQA6M0rR5EHIlXLiAvKAnUIY 6QMBXjChP6; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Discussing LISP deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 18:11:37 -0000 >>>>>> "Dino" == Dino Farinacci writes: > > Dino> I am going to answer them briefly one by one because the > Dino> answers are very simple. > > Dino, thanks for trying. Your answers were not as simple as you > thought they were: they were neither obviously correct nor > sufficiently clear that I understood them. I could probably engage in > a rapid fire discussion that would leave us both frustrated, but I > think it would be better to wait until we can discuss something more > organized. I do appreciate the response though. Sure, no problem. > Speaking only for myself; I'm definitely not trying to discourage > others from discussing. Discuss away. Dino From mrw@sandstorm.net Sat Aug 22 16:53:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665C73A690C for ; Sat, 22 Aug 2009 16:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23e8EVZNhd5y for ; Sat, 22 Aug 2009 16:53:37 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 9613C3A68CF for ; Sat, 22 Aug 2009 16:53:37 -0700 (PDT) Received: from [192.168.1.104] (cpe-72-224-235-56.maine.res.rr.com [72.224.235.56]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7MNrFtg004138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Aug 2009 19:53:23 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <27CFE3AB-8AA2-4593-B0ED-C4FCA4514C61@sandstorm.net> From: Margaret Wasserman To: Darrel Lewis (darlewis) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 22 Aug 2009 19:53:09 -0400 References: <20090821212009.D4A9E6BE557@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.935.3) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 22 Aug 2009 23:53:38 -0000 Hi Darrel, > I want to be clear above, the IPv4 packet's [UDP] checksum is > changed from 0 > to a non-zero (but correct) value on the NAT'd packet. Sorry if this > was unclear. Thanks for the clarification. This makes a _big_ (and very positive) difference in the discussions we've been having! Since these packets will contain a valid UDP checksum value, they will not be thrown away by an ETR checks non-zero checksums. Doesn't this remove our justification for forbidding ETRs from checking these checksums? I agree with Noel that this is still a bug, because it gives a false assurance of end-to-end integrity, but it is a _much_ less heinous bug than I had previously understood. Margaret From jnc@mercury.lcs.mit.edu Sun Aug 23 09:21:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED8E3A68E9 for ; Sun, 23 Aug 2009 09:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+lKlfuL4qy5 for ; Sun, 23 Aug 2009 09:21:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1F57E3A67A6 for ; Sun, 23 Aug 2009 09:21:27 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ED8046BE571; Sun, 23 Aug 2009 12:21:32 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090823162132.ED8046BE571@mercury.lcs.mit.edu> Date: Sun, 23 Aug 2009 12:21:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 23 Aug 2009 16:21:28 -0000 > From: Margaret Wasserman > This makes a _big_ (and very positive) difference in the discussions > we've been having! > ... > it is a _much_ less heinous bug than I had previously understood. Indeed, ditto. > Since these packets will contain a valid UDP checksum value, they will > not be thrown away by an ETR checks non-zero checksums. Doesn't this > remove our justification for forbidding ETRs from checking these checksums? Yes, as far as I can see. Is it OK to say 'ETRs MAY ignore non-zero UDP checksums on incoming encapsulated user-data packets'? (Or perhaps even 'SHOULD'?) It's not doing anything useful (the encapsulated packet is still protected by its own checksum), and so it's just useless overhead to check that checksum. Is it also the case that some forwarding boxes can't easily do the check (I'm assuming that if they can't _compute_ a checksum easily, they probably can't _check_ it either, for the same reason, whatever it is)? If so, we would have to have at least a 'MAY' on that. Noel From hartmans@mit.edu Sun Aug 23 12:07:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AED53A68D2 for ; Sun, 23 Aug 2009 12:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+hoRSFii5dv for ; Sun, 23 Aug 2009 12:07:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id A66163A6853 for ; Sun, 23 Aug 2009 12:07:02 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0EED364673; Sun, 23 Aug 2009 15:07:04 -0400 (EDT) To: Margaret Wasserman References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> From: Sam Hartman Date: Sun, 23 Aug 2009 15:07:04 -0400 In-Reply-To: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> (Margaret Wasserman's message of "Tue\, 11 Aug 2009 16\:24\:36 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 23 Aug 2009 19:07:03 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> I believe that (at least) seven separate issues have Margaret> been raised in the thread(s) about zero UDP checksums Margaret> that should be added to the LISP tracker, so that we can Margaret> track their resolution. These are all issues regarding Margaret> text in document version -03. I have entered these issues. Sorry about the delay: we were having trouble with the tracker. It's also being indecisive about whether it wants to e-mail the list. Margaret> #1: Sending UDP Zero Checksums Violates RFC 2460 This is #9 Margaret> #2: Sending UDP Zero Checksums not Universally Margaret> Implemented This is #10 Margaret> #3: Not Checking Inbound Non-Zero UDP Checksums Violates Margaret> RFC 1122 and RFC 2460 This is #11 Margaret> #4: Not Checking Inbound Non-Zero Checksums not Margaret> Universally Implemented. This is #12 Margaret> #5: Use of Zero UDP Checksums (in IPv4 and IPv6) Margaret> Requires Analysis This is #13 Margaret> #6: LAG/ECMP Requirements Not Well-Explained This is #14 Margaret> #7: Limits on "Gleaned" Map Entries Not Clear This is #8 From arifumi@nttv6.net Mon Aug 24 01:50:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B1E28C154 for ; Mon, 24 Aug 2009 01:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z0uTlFyIXGV for ; Mon, 24 Aug 2009 01:49:59 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2462128C100 for ; Mon, 24 Aug 2009 01:49:58 -0700 (PDT) Received: from [IPv6:2001:fa8:1000::714f:b4e:6e50:6992] ([IPv6:2001:fa8:1000:0:714f:b4e:6e50:6992]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n7O8o34r031035 for ; Mon, 24 Aug 2009 17:50:03 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 17:50:03 +0900 X-Mailer: Apple Mail (2.936) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 24 Aug 2009 17:50:03 +0900 (JST) Subject: [lisp] How to join the testbed X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 24 Aug 2009 08:50:00 -0000 Folks, I could not find any information how to join the lisp testbed on the web-site. Can somebody tell me how or any pointers ? -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From humbertogaliza@gmail.com Mon Aug 24 05:31:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0877328C1B5 for ; Mon, 24 Aug 2009 05:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsxI9zuEhr03 for ; Mon, 24 Aug 2009 05:31:45 -0700 (PDT) Received: from mail.dcc.ufba.br (mail.dcc.ufba.br [200.17.147.5]) by core3.amsl.com (Postfix) with ESMTP id 2089628C198 for ; Mon, 24 Aug 2009 05:31:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.dcc.ufba.br (Postfix) with ESMTP id 0E84EFDB for ; Mon, 24 Aug 2009 09:31:48 -0300 (BRT) Received: from mail.dcc.ufba.br ([127.0.0.1]) by localhost (jordan.dcc.ufba.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT4vZcdvGau5 for ; Mon, 24 Aug 2009 09:31:47 -0300 (BRT) Received: from scylla.local (unknown [10.2.200.107]) by mail.dcc.ufba.br (Postfix) with ESMTPSA id E778EF92 for ; Mon, 24 Aug 2009 09:31:47 -0300 (BRT) Message-ID: <4A928833.9040109@gmail.com> Date: Mon, 24 Aug 2009 09:31:47 -0300 From: Humberto Galiza User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Questions about LISP testing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 24 Aug 2009 12:31:46 -0000 Hello everyone, I'm relatively new to the list, so allow me a brief introduction. I'm an undergraduate student in Computer Science and currently work at the Point of Presence of National Network on Education and Research in Salvador, Bahia, Brazil. I have followed the discussions about the protocol LISP since last year, and since, I've developing a work of completion of undergraduate course about the scalability of Internet architecture, and as a possible solution, the use of LISP protocol. My main question is how can I make a proof of concept regarding the LISP functionalities. I have many doubts about what to test and how to test. So, in short: what we, as a single PoP, might actually do, to draw conclusions about the operation / deployment / protocol performance in a real scenario? If someone could show me some kind of documentation to respect, would be grateful. I thank the attention. Regards, Humberto Galiza From dmm@1-4-5.net Mon Aug 24 08:53:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E923A6E0F for ; Mon, 24 Aug 2009 08:53:23 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCwxt1CBik-2 for ; Mon, 24 Aug 2009 08:53:22 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 427963A6E6B for ; Mon, 24 Aug 2009 08:53:22 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n7OFrSbc017994; Mon, 24 Aug 2009 08:53:28 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n7OFrS9j017993; Mon, 24 Aug 2009 08:53:28 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 24 Aug 2009 08:53:28 -0700 From: David Meyer To: Arifumi Matsumoto Message-ID: <20090824155328.GA17784@1-4-5.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] How to join the testbed X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 24 Aug 2009 15:53:23 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 24, 2009 at 05:50:03PM +0900, Arifumi Matsumoto wrote: > Folks, > > I could not find any information how to join the lisp > testbed on the web-site. > > Can somebody tell me how or any pointers ? Arifumi, Basically you need someting that can speak LISP. AFAIK right now that is only Dino's implementation (there is an openLISP implentation which runs on freeBSD, but my understanding is that its a big behind the current set of spects). Once you have something that can speak LISP, you can splice on to an appropriate map-server.=20 Just a FYI -- on the current test network we're using=20 153.16/16 for v4 EID space and 2610:D0:/32 for v6 (see http://www.lisp4.net). I've been keeping the "registery" for these prefixes, so I need to assign those for you if/when you connect up.=20 Dave --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqSt3gACgkQORgD1qCZ2KcIRgCfeVAFFaz0JZQkbqUUDheH4zSf MJ0An1AgZzk3xGILgZLlUwfbdTXR2Bah =6c3w -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From lear@cisco.com Mon Aug 24 23:56:12 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C808E3A69C4 for ; Mon, 24 Aug 2009 23:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.169 X-Spam-Level: X-Spam-Status: No, score=-10.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr59InyZvmjE for ; Mon, 24 Aug 2009 23:56:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 60B873A6874 for ; Mon, 24 Aug 2009 23:56:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAHEnk0qQ/uCLe2dsb2JhbACBU5k0AQEWJAaiYYg3jzMFhBqBVohy X-IronPort-AV: E=Sophos;i="4.44,271,1249257600"; d="scan'208";a="47804460" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2009 06:56:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7P6uGFU027383; Tue, 25 Aug 2009 08:56:16 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp5582.cisco.com [10.61.85.205]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7P6uGPj004380; Tue, 25 Aug 2009 06:56:16 GMT Message-ID: <4A938B10.9090706@cisco.com> Date: Tue, 25 Aug 2009 08:56:16 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Sam Hartman References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2275; t=1251183376; x=1252047376; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20Checksum-related=20issues=20fo r=20the=20tracker |Sender:=20; bh=J7goKMht7taFzDXhuaDnK0D5LJI2I4ZNgvziv88qkK0=; b=p1dtHA1pvq+j+9luCMyXmMXuTWan0NpvIVICJnr3CQKS1Pl4XWagMm4JmK 4hc6e5CyFGsDxjELvD8GQv0yfKco1Ux1POBcD71CdZAkyW9aeigU5FQ5bjtq GTb+DQXu0+; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 06:56:12 -0000 Sam, I have a problem with the approach being taken by the chairs on this matter. Opening four issues on what amounts to substantially the same topic is a DOS attack on the WG and its time. Most egregious examples are 9 and 11. If one is expected to 0 checksums, then one should be expected to handle 0 checksums. I take Margaret's point that perhaps there might be some kernel implications in that perhaps an ioctl may needed to be added in some cases for participating implementations, but that has never been a serious consideration for holding back a change. Many people are going to be flying a long way to Hiroshima. Let's not burn it all on this, which yes, is the logical outcome of what you are doing. Eliot On 8/23/09 9:07 PM, Sam Hartman wrote: >>>>>> "Margaret" == Margaret Wasserman writes: >>>>>> > Margaret> I believe that (at least) seven separate issues have > Margaret> been raised in the thread(s) about zero UDP checksums > Margaret> that should be added to the LISP tracker, so that we can > Margaret> track their resolution. These are all issues regarding > Margaret> text in document version -03. > > I have entered these issues. Sorry about the delay: we were having > trouble with the tracker. It's also being indecisive about whether it > wants to e-mail the list. > > Margaret> #1: Sending UDP Zero Checksums Violates RFC 2460 > > This is #9 > > Margaret> #2: Sending UDP Zero Checksums not Universally > Margaret> Implemented > > This is #10 > Margaret> #3: Not Checking Inbound Non-Zero UDP Checksums Violates > Margaret> RFC 1122 and RFC 2460 > > This is #11 > > Margaret> #4: Not Checking Inbound Non-Zero Checksums not > Margaret> Universally Implemented. > > This is #12 > > Margaret> #5: Use of Zero UDP Checksums (in IPv4 and IPv6) > Margaret> Requires Analysis > > This is #13 > > Margaret> #6: LAG/ECMP Requirements Not Well-Explained > > This is #14 > Margaret> #7: Limits on "Gleaned" Map Entries Not Clear > > This is #8 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > From hartmans@mit.edu Tue Aug 25 03:48:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391DB3A6803 for ; Tue, 25 Aug 2009 03:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9LPTSZuotIH for ; Tue, 25 Aug 2009 03:48:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 51EB728C1D5 for ; Tue, 25 Aug 2009 03:48:11 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 24BB264673; Tue, 25 Aug 2009 06:48:16 -0400 (EDT) To: Eliot Lear References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> <4A938B10.9090706@cisco.com> From: Sam Hartman Date: Tue, 25 Aug 2009 06:48:16 -0400 In-Reply-To: <4A938B10.9090706@cisco.com> (Eliot Lear's message of "Tue\, 25 Aug 2009 08\:56\:16 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 10:48:13 -0000 Your concern is noted. I respectfully disagree. I'm going to respond to the technical part of your concern because I think getting in a long process discussion would be more of a DOS than opening any four issues in a database. I absolutely agree that discussing each of Margaret's seven issues in turn, giving them equal time, would be a bad way to run a meeting. If we're still needing to send any face to face time on this at IETF 76, I'll have already clawed out my eyes and removed my ears in frustration:-). Fixing this is definitely not about adding a kernel IOCTL. There are significant architectural, political and hardware issues to implementing ignore UDP checksums. Architectural: So, let's assume you want to add this mythical IOCTL to enable receiving checksums. It would be either a socket option or a sysctl, not an ioctl. A global sysctl is bad: you don't want to ignore UDP checksums for all applications. Even LISP cares about checksums for the control plane. However in most OSes the UDP checksum is verified before the kernel demultiplexes the packet and determines what to do with it. So, you need to reorganize the kernel code for the UDP stack for the entire operating system in order to implement this feature. It's possible to do certainly, but it's a kind of major change. hardware: As we've discussed there are a huge number of NICs that offload IPV6 checksum processing. I don't know how easy it is to ignore checksum errors on these; accepting 0 checksums for IPV6 may be even more challenging. political: Linux has just gotten done removing the ability to send 0 checksums because we (the IETF) have spent the last 10 years convincing the world that's a bad idea. Windows is in a similar place. I have enough information about the political situation within Linux, Apple and microsoft to strongly guess that LISP is not a big enough consumer to motivate changes in this area. So, no, I definitely don't think this is all about an IOCTL. I do think it is all doable;I do think that if we get to a point where the WG has consensus behind the LAG and NAT traversal requirements that a solution will be achieved quickly. From lear@cisco.com Tue Aug 25 05:40:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4293A6F1A for ; Tue, 25 Aug 2009 05:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1MKy7Lup3yM for ; Tue, 25 Aug 2009 05:40:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AF29128C28B for ; Tue, 25 Aug 2009 05:40:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAE54k0qQ/uCKe2dsb2JhbACBU5k4AQEWJAajKYg3j1wFhBqBVohy X-IronPort-AV: E=Sophos;i="4.44,272,1249257600"; d="scan'208";a="47837398" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2009 12:40:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7PCeSlm011517; Tue, 25 Aug 2009 14:40:28 +0200 Received: from adsl-247-3-fixip.tiscali.ch (dhcp-10-61-103-193.cisco.com [10.61.103.193]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7PCeSPj010179; Tue, 25 Aug 2009 12:40:28 GMT Message-ID: <4A93DBBC.4020704@cisco.com> Date: Tue, 25 Aug 2009 14:40:28 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Sam Hartman References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> <4A938B10.9090706@cisco.com> In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3194; t=1251204028; x=1252068028; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20Checksum-related=20issues=20fo r=20the=20tracker |Sender:=20; bh=z+QLqtitlvcjCbGuKKXsAOeXwi4Rw6/zBfR4OLSQftY=; b=sTGgEtZUDKYrh49+FMdseuXZWFDrDFW1onTUNn7sn5kfvVEwhKPE+ivd7k 6XiL80mgn8sqlGal0dcL+BWxh4PAtQlz7CvKoTxpqgzbERGxr8gSFS+ArcKs kut96TAsM8; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 12:40:54 -0000 Sam, On 8/25/09 12:48 PM, Sam Hartman wrote: > Your concern is noted. I respectfully disagree. I'm going to respond > to the technical part of your concern because I think getting in a > long process discussion would be more of a DOS than opening any four > issues in a database. I absolutely agree that discussing each of > Margaret's seven issues in turn, giving them equal time, would be a > bad way to run a meeting. If we're still needing to send any face to > face time on this at IETF 76, I'll have already clawed out my eyes and > removed my ears in frustration:-). > Then if it's bad way to run the meeting, it's a bad way, period. It's still a process DOS attack. > Fixing this is definitely not about adding a kernel IOCTL. There are > significant architectural, political and hardware issues to > implementing ignore UDP checksums. > Margaret made a claim that it would be difficult separate certain types of traffic for the check, and I just don't believe that is technically true. That is what I responded to. > Architectural: So, let's assume you want to add this mythical IOCTL to > enable receiving checksums. It would be either a socket option or a > sysctl, not an ioctl. A global sysctl is bad: you don't want to > ignore UDP checksums for all applications. Right. > Even LISP cares about > checksums for the control plane. Right. > However in most OSes the UDP > checksum is verified before the kernel demultiplexes the packet and > determines what to do with it. So, you need to reorganize the kernel > code for the UDP stack for the entire operating system in order to > implement this feature. It's possible to do certainly, but it's a > kind of major change. > Order of magnitude effort to make that change? Reorder how many lines of code? 1 (assuming a function, perhaps inline). > hardware: As we've discussed there are a huge number of NICs that > offload IPV6 checksum processing. I don't know how easy it is to > ignore checksum errors on these; accepting 0 checksums for IPV6 may be > even more challenging. > That's a fair point (thus far the only one). But just as there is a lot of h/w that doesn't support IPv6, there could be h/w that doesn't support LISP. > political: Linux has just gotten done removing the ability to send 0 > checksums because we (the IETF) have spent the last 10 years > convincing the world that's a bad idea. Windows is in a similar > place. I have enough information about the political situation within > Linux, Apple and microsoft to strongly guess that LISP is not a big > enough consumer to motivate changes in this area. > It's a matter of who does the work, and what the motivations are. I also think you speak quite loosely and authoritatively for those organizations. If there is value in LISP to those groups and vendors, they'll make the change. If there is value in the OpenSource world to consumers making the change, the consumer will make the change. I take your point about politics, but one thing we've learned is that perhaps nuance is something that has been lacking All of This. Eliot From mrw@lilacglade.org Tue Aug 25 07:40:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD523A6906 for ; Tue, 25 Aug 2009 07:40:45 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG5O-bI9oK-r for ; Tue, 25 Aug 2009 07:40:44 -0700 (PDT) Received: from QMTA14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 3B94F3A6A5B for ; Tue, 25 Aug 2009 07:40:44 -0700 (PDT) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA14.westchester.pa.mail.comcast.net with comcast id YbCd1c0091ei1Bg5EegryB; Tue, 25 Aug 2009 14:40:51 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA24.westchester.pa.mail.comcast.net with comcast id Yekg1c0011cMU3H3keki8D; Tue, 25 Aug 2009 14:44:46 +0000 Message-Id: From: Margaret Wasserman To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 10:40:41 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 14:40:45 -0000 Now that the UDP checksum issues have been entered into the tracker, I think we can try to agree to a resolution for the following issues: Issue #9 Sending UDP Zero Checksums Violates RFC 2460 Issue #10 Sending UDP Zero Checksums not Universally Implemented Issue #12 Not Checking Inbound Non-Zero Checksums not Universally Implemented Sam had proposed some wording earlier, and Dino had offered to put it in the -04 draft. I then suggested that we add a normative reference to Marshall Eubanks' IPv6 zero UDP checksum draft to allow sending zero UDP checksums in IPv6. Noel objected to making it optional to ignore UDP checksums because of concerns that widely-deployed NATs would corrupt a zero UDP checksum and packets could be black-holed. Since then, we have determined that those NATs change the UDP checksum to a correct checksum value, so that concern has been eliminated. So, at this point, I think we may have agreement on the following changes: OLD (-03 version): UDP Checksum: this field MUST be transmitted as 0 and ignored on receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. For performance reasons, the ETR MUST ignore the checksum and MUST not do a checksum computation. NEW (proposed -04 version): UDP Checksum: this field MAY be transmitted as 0 in both IPv4 and IPv6 packets [draft-eubanks-chimento-6man-00.txt], and MAY be ignored by the ETR. + Add a normative reference to draft-eubanks-chimento-6man-00. Does anyone object to making the change shown above to resolve issues #9, #10 and #12? Margaret From tme@americafree.tv Tue Aug 25 07:45:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDC23A6EB9 for ; Tue, 25 Aug 2009 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfr2OxcqfJHN for ; Tue, 25 Aug 2009 07:45:23 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 843893A6D95 for ; Tue, 25 Aug 2009 07:45:23 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id CDD5A491C72A; Tue, 25 Aug 2009 10:45:29 -0400 (EDT) Message-Id: <0986B0C3-48D0-40EE-AF2D-E8925FBCD1B0@americafree.tv> From: Marshall Eubanks To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 10:45:29 -0400 References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> <4A938B10.9090706@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 14:45:24 -0000 On Aug 25, 2009, at 6:48 AM, Sam Hartman wrote: > Your concern is noted. I respectfully disagree. I'm going to respond > to the technical part of your concern because I think getting in a > long process discussion would be more of a DOS than opening any four > issues in a database. I absolutely agree that discussing each of > Margaret's seven issues in turn, giving them equal time, would be a > bad way to run a meeting. If we're still needing to send any face to > face time on this at IETF 76, I'll have already clawed out my eyes and > removed my ears in frustration:-). > > Fixing this is definitely not about adding a kernel IOCTL. There are > significant architectural, political and hardware issues to > implementing ignore UDP checksums. > > Architectural: So, let's assume you want to add this mythical IOCTL to > enable receiving checksums. It would be either a socket option or a > sysctl, not an ioctl. A global sysctl is bad: you don't want to > ignore UDP checksums for all applications. Even LISP cares about > checksums for the control plane. However in most OSes the UDP > checksum is verified before the kernel demultiplexes the packet and > determines what to do with it. So, you need to reorganize the kernel > code for the UDP stack for the entire operating system in order to > implement this feature. It's possible to do certainly, but it's a > kind of major change. > > hardware: As we've discussed there are a huge number of NICs that > offload IPV6 checksum processing. I don't know how easy it is to > ignore checksum errors on these; accepting 0 checksums for IPV6 may be > even more challenging. > Is there any operational experience with v6 LISP and zero UDP checksums ? I would be curious how difficult it is to pass these around in practice. Regards Marshall > political: Linux has just gotten done removing the ability to send 0 > checksums because we (the IETF) have spent the last 10 years > convincing the world that's a bad idea. Windows is in a similar > place. I have enough information about the political situation within > Linux, Apple and microsoft to strongly guess that LISP is not a big > enough consumer to motivate changes in this area. > > So, no, I definitely don't think this is all about an IOCTL. I do > think it is all doable;I do think that if we get to a point where the > WG has consensus behind the LAG and NAT traversal requirements that a > solution will be achieved quickly. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From lars.eggert@nokia.com Tue Aug 25 07:59:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5C23A6B11 for ; Tue, 25 Aug 2009 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vOiJ+ocz3Bt for ; Tue, 25 Aug 2009 07:59:55 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 19E7C28C285 for ; Tue, 25 Aug 2009 07:59:26 -0700 (PDT) Received: from wifi-visiteurs-107.sri.ucl.ac.be (wifi-visiteurs-107.sri.ucl.ac.be [130.104.202.235]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7PExOgV031318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Aug 2009 17:59:24 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> From: Lars Eggert To: Margaret Wasserman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-64-174737484; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 16:59:20 +0200 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 14:59:55 -0000 --Apple-Mail-64-174737484 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-8-25, at 16:40, Margaret Wasserman wrote: > Since then, we have determined that those NATs change the UDP checksum > to a correct checksum value, so that concern has been eliminated. this is overstating things. Here is what Darrel wrote: > Many commercial (netgear and linksys being two that come to mind) > NATs do > indeed recalculate the checksum regardless of its initial value. I understand this to mean that some Netgear and Linksys models behaved OK in testing. It's not clear which models (all?). It's also not clear if any NATs were tested that had a different behavior. Is there more data from these tests available? One lesson we learned in BEHAVE is that there is *no* regularity in what deployed NATs do. (Ask Cullen for war stories.) To close this issue, I believe we need to convince ourselves that most NATs out there have this behavior, and not just some models from two vendors. Lars --Apple-Mail-64-174737484 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDgyNTE0NTkyMVowIwYJKoZIhvcNAQkEMRYEFFhs+3m1sD4nlimBvY1HGxIp4XXGMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBEdgwFNvOrURCGMTPOvVVUoheZlT7TcFO/0BgrM+Eb9GRzsEtmRsJubZRYRExbBH074EgB uC5bA8gu0eXPTxG/PYTqvy0oMIEOlnPnTozccvx6r4X+AxuWRhA7mWXau+jUgACsgqL18ttslm7v ckiMJI8XN6aGXJliAha90S/K589AS8w33M82lVWOs91QXt77XXW12brdkh4q+Z4unHQsvYpBWJAx UvQdgAxU034pojJncIJJA72kQZ7C4DeKTQBV+76aF7CqGf+3592GcmtCPFdUlsuCUNpG7Vl+HzZf gFJQWnfL92wzJLcmxLo2T8pt6+Y6Ah/bvwJgEGCHKKi2AAAAAAAA --Apple-Mail-64-174737484-- From hartmans@mit.edu Tue Aug 25 08:23:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56793A6E2B for ; Tue, 25 Aug 2009 08:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HgjQsDGWat2 for ; Tue, 25 Aug 2009 08:23:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 337A93A6C25 for ; Tue, 25 Aug 2009 08:23:00 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3DCFD64673; Tue, 25 Aug 2009 11:23:04 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 25 Aug 2009 11:23:04 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] (#11) Do we still have a reason to ignore non-zero UDP checksums? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 15:23:01 -0000 Hi. So it sounds like from discussions between Darrel, Noel and Margaret last week, Last week, discussion between Darrel, Noel and Margaret indicated that Darrel is unaware of NATs that replace 0 UDP checksums with invalid UDP checksums. Are their remaining arguments in favor of permitting a receiver to ignore a non-zero UDP checksum? From mrw@lilacglade.org Tue Aug 25 08:25:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C03A6900 for ; Tue, 25 Aug 2009 08:25:19 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zl+uelSZIUJ for ; Tue, 25 Aug 2009 08:25:18 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 5AC733A680D for ; Tue, 25 Aug 2009 08:25:18 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id Yexw1c00416AWCUA3fRRNx; Tue, 25 Aug 2009 15:25:25 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id YfRD1c0081cMU3H8SfRGb2; Tue, 25 Aug 2009 15:25:23 +0000 Message-Id: From: Margaret Wasserman To: Lars Eggert In-Reply-To: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 11:25:11 -0400 References: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 15:25:19 -0000 Hi Lars, On Aug 25, 2009, at 10:59 AM, Lars Eggert wrote: > On 2009-8-25, at 16:40, Margaret Wasserman wrote: >> Since then, we have determined that those NATs change the UDP >> checksum >> to a correct checksum value, so that concern has been eliminated. > > this is overstating things. Here is what Darrel wrote: > >> Many commercial (netgear and linksys being two that come to mind) >> NATs do >> indeed recalculate the checksum regardless of its initial value. > > I understand this to mean that some Netgear and Linksys models > behaved OK in testing. It's not clear which models (all?). It's also > not clear if any NATs were tested that had a different behavior. Is > there more data from these tests available? The only reason that we even considered the issue of NATs that change zero (IPv4) UDP checksums to non-zero values was that we were told, by folks from Cisco, that there were widely deployed NATs (from Linksys and Netgear) that would modify IPv4 zero UDP checksums to non-zero values. Both Noel and I made the (mistaken) assumption that those NATs would modify the values to _incorrect_ UDP checksum values, and we ran off from there. It turns out that those NATs modify the checksums to _correct_ UDP checksum values, so all of our discussion about what would happen if they included incorrect values was moot. So, no, we haven't gone and tested any significant number of NATs. But, I don't understand why we would need do so, as our discussion about NATs that change zero checksums into bad checksums was entirely based on a misunderstanding. This is all entirely separate from any discussion of how/if existing hardware and software will handle IPv6 zero UDP checksums. Presumably, 6man (with help from transport folks) will need to consider that question in their discussions of the eubanks-chimento draft. If the 6man group decides to go forward with the eubanks- chimento draft, then LISP can use it. Otherwise, LISP will have to use whatever the 6man group recommends instead, I guess... Margaret From dino@cisco.com Tue Aug 25 08:45:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608F73A6ABA for ; Tue, 25 Aug 2009 08:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjAy0yYpr-+W for ; Tue, 25 Aug 2009 08:45:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8278F3A6B61 for ; Tue, 25 Aug 2009 08:45:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANujk0qrR7PD/2dsb2JhbAC/d4g5j2oFhBqKUQ X-IronPort-AV: E=Sophos;i="4.44,272,1249257600"; d="scan'208";a="374896776" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2009 15:46:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7PFk1Ww031923; Tue, 25 Aug 2009 08:46:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7PFk1Yx017296; Tue, 25 Aug 2009 15:46:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 08:46:01 -0700 Received: from [192.168.1.5] ([10.21.116.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 08:46:00 -0700 Message-Id: <3D4E120D-0FCB-4B89-B0FA-8D62D912C61C@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 08:46:00 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Aug 2009 15:46:00.0743 (UTC) FILETIME=[252E4B70:01CA259B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=305; t=1251215161; x=1252079161; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20(#11)=20Do=20we=20still=20have =20a=20reason=20to=20ignore=20non-zero=20UDP=20checksums? |Sender:=20; bh=cZRWckSxcuYF4nfNnaiLdZr+Z1hcgpX7vYR4gZsXgAE=; b=L7Ry+2lb4MSPLsksCBUpZQGltgSPkG1RrYVOzcEvkQkqNKdVqxsU3rE1nm FqMRfElN6j0Ddo6uM+zEqwOypjwIe14JF1f80Hrbwlr0biIduk0ZkHLTdQ0K 6jfBzpLAbs; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] (#11) Do we still have a reason to ignore non-zero UDP checksums? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 15:45:56 -0000 > Are their remaining arguments in favor of permitting a receiver to > ignore a non-zero UDP checksum? There is still the cost of doing it in router hardware. That, in and of itself, is reason to ignore it regardless if the encapsulator is setting the UDP checksum to zero or non-zero. Dino From dino@cisco.com Tue Aug 25 08:54:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCF53A6ABA for ; Tue, 25 Aug 2009 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrhlwTjbNFd2 for ; Tue, 25 Aug 2009 08:54:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 793593A6942 for ; Tue, 25 Aug 2009 08:54:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+mk0qrR7PE/2dsb2JhbAC/cYg5j2sFhBo X-IronPort-AV: E=Sophos;i="4.44,273,1249257600"; d="scan'208";a="91200478" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2009 15:54:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7PFsmJR006030; Tue, 25 Aug 2009 08:54:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7PFsiFW019700; Tue, 25 Aug 2009 15:54:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 08:54:48 -0700 Received: from [192.168.1.5] ([10.21.116.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 08:54:47 -0700 Message-Id: <4ACF9CB5-43C2-43D8-A402-BB8E35BC6ACF@cisco.com> From: Dino Farinacci To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 08:54:47 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Aug 2009 15:54:47.0838 (UTC) FILETIME=[5F5A9BE0:01CA259C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=156; t=1251215688; x=1252079688; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Resolving=20Issues=20#9,=20#10 =20and=20#12?=20(UDP=20Checksums) |Sender:=20; bh=kQDm6F6zDXPrsrXSHMaQSjY4QlaPUH85LnGpp2XYD8A=; b=eszpVgH6WDJYmVr1czbnF0NStaBlkQtYwPUCcn9y/N2eNLDXO+Q12yuvBf bPy4zyQ0DpmPbI5uJVKPCXTGGUspduYAiEzwsoAjeXLPpPGXjCQhYtHjKWZ1 Q+pz72dvCN; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 15:54:43 -0000 > Sam had proposed some wording earlier, and Dino had offered to put it > in the -04 draft. My proposed changes will be posted by end of week. Dino From mrw@sandstorm.net Tue Aug 25 08:57:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E2E28C466 for ; Tue, 25 Aug 2009 08:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WtCnrHRKcG4 for ; Tue, 25 Aug 2009 08:57:40 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id B83773A6EF3 for ; Tue, 25 Aug 2009 08:57:40 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7PFvJL0073624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2009 11:57:20 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 11:57:19 -0400 References: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 15:57:41 -0000 Hi Lars, On Aug 25, 2009, at 11:25 AM, Margaret Wasserman wrote: > So, no, we haven't gone and tested any significant number of NATs. > But, I don't understand why we would need do so, as our discussion > about NATs that change zero checksums into bad checksums was > entirely based on a misunderstanding. Just to make something clearer here... The issues that I suggested we resolve are _not_ the issues with LISP working through NAT boxes in general. There is ongoing discussion of whether LISP needs to work through NAT boxes, and if we do want LISP to work through NATs, I have mentioned several ways in which the current LISP spec would not work through IPv4 NAT boxes. Those issues have not been resolved. That discussion has not been reflected in the issue tracker yet, but I assume it will be. I am only suggesting that we close three of the UDP checksum-related issues. Two checksum-related issues would remain open: Issue #11: Not Checking Inbound Non-Zero UDP Checksums Violates RFC [1812] and RFC 2460 Issue #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis Also, the resolution I suggested adds a normative reference to draft- eubanks-chimento..., so LISP could only proceed with the use of UDP zero checksums in IPv6 if that draft is adopted in 6man (or elsewhere) and published as a standards-track RFC. Margaret From tme@americafree.tv Tue Aug 25 09:36:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DAE3A69D3 for ; Tue, 25 Aug 2009 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+nCjUwwhxYU for ; Tue, 25 Aug 2009 09:36:45 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 8C10A3A6C46 for ; Tue, 25 Aug 2009 09:36:45 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id EEA88491F3E1; Tue, 25 Aug 2009 12:36:50 -0400 (EDT) Message-Id: <2FD73F02-0A98-4A54-96BD-55B1B42D0C9E@americafree.tv> From: Marshall Eubanks To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 12:36:50 -0400 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] (#11) Do we still have a reason to ignore non-zero UDP checksums? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 16:36:46 -0000 On Aug 25, 2009, at 11:23 AM, Sam Hartman wrote: > > > Hi. So it sounds like from discussions between Darrel, Noel and > Margaret last week, Last week, discussion between Darrel, Noel and > Margaret indicated that Darrel is unaware of NATs that replace 0 UDP > checksums with invalid UDP checksums This is clearly not a protocol compliant behavior. Will they do this in 10 years ? Should protocols be limited for all time because of what "widely-deployed, buggy NAT boxes" do now ? I would be in favor (of Margaret's 3 choices) (1) Decide that it is not that important for LISP to work across those buggy NAT boxes (or that other things are more important), AND convince the IETF that is okay to send zero UDP checksums in IPv6. As for what to do with incorrect buggy NAT checksums, I would say that these MAY be ignored by implementations of LISP (i.e., that these be left to implementors). Regards Marshall Regards Marshall > . > > Are their remaining arguments in favor of permitting a receiver to > ignore a non-zero UDP checksum? > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From tme@americafree.tv Tue Aug 25 09:47:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC03B3A6F25 for ; Tue, 25 Aug 2009 09:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk8dewQosD4C for ; Tue, 25 Aug 2009 09:47:16 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id CE9B93A69D3 for ; Tue, 25 Aug 2009 09:47:15 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 10CD3491F826; Tue, 25 Aug 2009 12:47:22 -0400 (EDT) Message-Id: <01C4103B-8D53-4E75-80D6-0738F9F2BC46@americafree.tv> From: Marshall Eubanks To: Margaret Wasserman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 12:47:17 -0400 References: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 16:47:16 -0000 On Aug 25, 2009, at 11:57 AM, Margaret Wasserman wrote: > > Hi Lars, > > On Aug 25, 2009, at 11:25 AM, Margaret Wasserman wrote: >> So, no, we haven't gone and tested any significant number of NATs. >> But, I don't understand why we would need do so, as our discussion >> about NATs that change zero checksums into bad checksums was >> entirely based on a misunderstanding. > > Just to make something clearer here... > > The issues that I suggested we resolve are _not_ the issues with > LISP working through NAT boxes in general. There is ongoing > discussion of whether LISP needs to work through NAT boxes, and if > we do want LISP to work through NATs, I have mentioned several ways > in which the current LISP spec would not work through IPv4 NAT > boxes. Those issues have not been resolved. That discussion has > not been reflected in the issue tracker yet, but I assume it will be. > > I am only suggesting that we close three of the UDP checksum-related > issues. Two checksum-related issues would remain open: > > Issue #11: Not Checking Inbound Non-Zero UDP Checksums Violates RFC > [1812] and RFC 2460 > Issue #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires > Analysis > > Also, the resolution I suggested adds a normative reference to draft- > eubanks-chimento..., so LISP could only proceed with the use of UDP > zero checksums in IPv6 if that draft is adopted in 6man (or > elsewhere) and published as a standards-track RFC. > Dear Margaret; At present, draft-eubanks-chimento... effectively deals with Issue 13 not Issue 11. Are you proposing that it deal with # 11 as well ? As something informational or as a MUST ? Regards Marshall > Margaret > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Tue Aug 25 09:50:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5063A69D3 for ; Tue, 25 Aug 2009 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py2UNhvncD3g for ; Tue, 25 Aug 2009 09:50:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B17673A68E6 for ; Tue, 25 Aug 2009 09:50:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2D7A86BE5E9; Tue, 25 Aug 2009 12:50:40 -0400 (EDT) To: lisp@ietf.org, tme@americafree.tv Message-Id: <20090825165040.2D7A86BE5E9@mercury.lcs.mit.edu> Date: Tue, 25 Aug 2009 12:50:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] (#11) Do we still have a reason to ignore non-zero UDP checksums? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 16:50:35 -0000 > From: Marshall Eubanks >> Darrel is unaware of NATs that replace 0 UDP checksums with invalid >> UDP checksums In other words, 'Darrel does not know of any NATs which replace 0 UDP checksums with invalid UDP checksums'. > This is clearly not a protocol compliant behavior. ... > (1) Decide that it is not that important for LISP to work across those > buggy NAT boxes > As for what to do with incorrect buggy NAT checksums _As far as we know_, there are no buggy NAT checksums. Noel From tme@americafree.tv Tue Aug 25 10:00:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5359B3A6BC5 for ; Tue, 25 Aug 2009 10:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIaADmFgYHH6 for ; Tue, 25 Aug 2009 10:00:42 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 5E4D73A6B61 for ; Tue, 25 Aug 2009 10:00:42 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9E4B5491FE1B; Tue, 25 Aug 2009 13:00:47 -0400 (EDT) Message-Id: <0F5AE9CB-904D-435C-B118-9D9ED28EEE34@americafree.tv> From: Marshall Eubanks To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090825165040.2D7A86BE5E9@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 13:00:45 -0400 References: <20090825165040.2D7A86BE5E9@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] (#11) Do we still have a reason to ignore non-zero UDP checksums? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 17:00:43 -0000 On Aug 25, 2009, at 12:50 PM, Noel Chiappa wrote: >> From: Marshall Eubanks > >>> Darrel is unaware of NATs that replace 0 UDP checksums with invalid >>> UDP checksums > > In other words, 'Darrel does not know of any NATs which replace 0 UDP > checksums with invalid UDP checksums'. > >> This is clearly not a protocol compliant behavior. ... >> (1) Decide that it is not that important for LISP to work across >> those >> buggy NAT boxes >> As for what to do with incorrect buggy NAT checksums > > _As far as we know_, there are no buggy NAT checksums. Yes, I caught that from the recent discussion (and, obviously, that's a Really Good Thing). My point was, _even if some are found_, they shouldn't drive the protocol work. Regards Marshall > > Noel > From mrw@sandstorm.net Tue Aug 25 10:40:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54263A6FA3 for ; Tue, 25 Aug 2009 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uniaRh7iULN for ; Tue, 25 Aug 2009 10:40:13 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 62A413A6FA0 for ; Tue, 25 Aug 2009 10:40:12 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7PHe7N4080193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2009 13:40:07 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <61579DED-0742-45F6-926E-BA8347C0B781@sandstorm.net> From: Margaret Wasserman To: Marshall Eubanks In-Reply-To: <01C4103B-8D53-4E75-80D6-0738F9F2BC46@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 13:40:06 -0400 References: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> <01C4103B-8D53-4E75-80D6-0738F9F2BC46@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 17:40:15 -0000 On Aug 25, 2009, at 12:47 PM, Marshall Eubanks wrote: >> >> I am only suggesting that we close three of the UDP checksum- >> related issues. Two checksum-related issues would remain open: >> >> Issue #11: Not Checking Inbound Non-Zero UDP Checksums Violates RFC >> [1812] and RFC 2460 >> Issue #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires >> Analysis >> >> Also, the resolution I suggested adds a normative reference to >> draft-eubanks-chimento..., so LISP could only proceed with the use >> of UDP zero checksums in IPv6 if that draft is adopted in 6man (or >> elsewhere) and published as a standards-track RFC. >> > > Dear Margaret; > > At present, draft-eubanks-chimento... effectively deals with Issue > 13 not Issue 11. Are you proposing that it > deal with # 11 as well ? As something informational or as a MUST ? I did not say that a reference to draft-eubanks-chimento would resolve issue #13. In fact, I explictly stated (as shown above) that #13 would remain open. As to whether draft-eubanks-chimento... _should_ include the ability to ignore non-zero checksums: First, let me say that I am not sure that we should publish draft- eubanks-chimento... at all, because I do not think that the use of IPv6 UDP checksums should be optional. On the technical purity side, I'd say: If protocols need an encapsulation that doesn't include full-packet integrity checking, they should use something other than UDP. IPv6 load balancers should be built to use the flow label as one input for their hash, and protocols that are using the UDP header only for load balancing, should put their per-flow hash into the flow label. Hardware that can't calculate UDP checksums efficiently should be replaced with hardware that can. But, it seems like there is a large group of people in the IETF who don't like that answer, some of them for pretty compelling reasons... If we _do_ decide to allow zero UDP checksums in IPv6 it will be for three reasons: (1) We understand that there is equipment that cannot calculate UDP checksums efficiently. (2) We accept that it is important to use a UDP/IPv6 encapsulation in many cases (as opposed to UDP-Lite or direct IP encapsulation), to be compatible with deployed IPv6 LAG/ECMP equipment and/or IPv6 firewalls. (3) We believe that there are protocols for which integrity protection of the IP and UDP headers is unnecessary. I am somewhat skeptical that there is enough IPv6 LAG/ECMP equipment deployed that will not be upgraded in the time it takes to reach wide deployment of a new protocol that we should consider this. Perhaps we should right an RFC about how to achieve IPv6 LAG/ECMP using the flow label instead? Others seem to think that this is something we should consider, however. The third point is key, and it is the place where I think draft- eubanks-chimento... needs work. Exactly what properties does a protocol need to have to fall into this category? What type of analysis is needed to determine that it would be safe to run a given protocol without integrity checking for the outer headers? Does this include protocols (like LISP) that introduce their own header between the outer and inner IP headers? Or only to mechanisms, like IPv6-in- IPv4 tunneling mechanisms, that tunnel IP directly in UDP/IP? If we _do_ decide that it is okay for protocols to send zero IPv6 UDP checksums in some cases for the reasons stated above, what would be the benefit of forcing those same protocols to calculate non-zero received checksums? The other end would, most likely, run on the same type of hardware (the hardware that can't calculate full-packet checksums efficiently). And, the protocol would be the same protocol (the one that wouldn't benefit from end-to-end integrity checking). So, what would be the point of requiring the receiving end to check all non-zero checksums if we don't require the sending end to send non- zero checksums? So, I guess it would make sense to include the option for the receiving end to ignore non-zero UDP checksums in the same cases where we allow the sender to send zero IPv6 UDP checksums. I am just not sure that there are any cases where we should do that. Margaret Margaret From mrw@sandstorm.net Tue Aug 25 10:47:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40203A6FA8 for ; Tue, 25 Aug 2009 10:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYOGp6JwNTF4 for ; Tue, 25 Aug 2009 10:47:57 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 2E18C3A68B3 for ; Tue, 25 Aug 2009 10:47:57 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7PHm1vZ080559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2009 13:48:01 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <56E44FA5-CCC2-40E7-BCE5-8B4A8DFF99BE@sandstorm.net> From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: <61579DED-0742-45F6-926E-BA8347C0B781@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 25 Aug 2009 13:48:01 -0400 References: <565DA93D-12EC-4C61-9EBF-FA3C1E21FB6A@nokia.com> <01C4103B-8D53-4E75-80D6-0738F9F2BC46@americafree.tv> <61579DED-0742-45F6-926E-BA8347C0B781@sandstorm.net> X-Mailer: Apple Mail (2.935.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2009 17:47:58 -0000 Hi Marshall, On Aug 25, 2009, at 1:40 PM, Margaret Wasserman wrote: >> >> At present, draft-eubanks-chimento... effectively deals with Issue >> 13 not Issue 11. Are you proposing that it >> deal with # 11 as well ? As something informational or as a MUST ? > > > I did not say that a reference to draft-eubanks-chimento would > resolve issue #13. In fact, I explictly stated (as shown above) > that #13 would remain open. I'm sorry, I meant that issue #11 would remain open if we adopt my proposed change, because it is not (currently) resolved by draft- eubanks-chimento...: Issue #11: Not Checking Inbound Non-Zero UDP Checksums Violates RFC [1812] and RFC 2460 > > I am somewhat skeptical that there is enough IPv6 LAG/ECMP equipment > deployed that will not be upgraded in the time it takes to reach > wide deployment of a new protocol that we should consider this. > Perhaps we should right an RFC about how to achieve IPv6 LAG/ECMP > using the flow label instead? Others seem to think that this is > something we should consider, however. s/right an RFC/write an RFC I really should try to hit send a little less quickly... Margaret From dino@cisco.com Wed Aug 26 00:19:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E47E3A6EDA for ; Wed, 26 Aug 2009 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=-1.960, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgJ4u4fmYXp1 for ; Wed, 26 Aug 2009 00:19:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0B2FC3A7078 for ; Wed, 26 Aug 2009 00:19:29 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html : 151698 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAId+lEqrR7PD/2dsb2JhbACCJDK8S4g5KZAWBYIzAQQIgVqBWIkg X-IronPort-AV: E=Sophos;i="4.44,278,1249257600"; d="html'217?scan'217,208,217";a="233187825" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Aug 2009 07:19:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7Q7JVHW028304; Wed, 26 Aug 2009 00:19:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7Q7JVm7013180; Wed, 26 Aug 2009 07:19:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 00:19:31 -0700 Received: from [192.168.1.5] ([10.21.68.117]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 00:19:30 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-44-233546462 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 26 Aug 2009 00:19:29 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 Aug 2009 07:19:30.0585 (UTC) FILETIME=[8DA5F090:01CA261D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=159431; t=1251271171; x=1252135171; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Proposed=20changes=20to=20draft-ietf-lisp-04.tx t |Sender:=20; bh=xxVrYiQ4c15KvasWW67xDS+DpVBmTvv0gS5XSKEli8o=; b=athUKWJ9i+kPTjbbI9AXG1AjhEaUko9hVY0GPTzIG/ZyTPZ62n/vOPoIPF 18ghHsUuQD4qxPm/oQnIyw3TrSNUiVXOu0VgYffE3hSv9hQ1gC5TVj/b0oUF 6kVCM5mw28; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Andrew Partan , "lispers list\)" , Noel Chiappa Subject: [lisp] Proposed changes to draft-ietf-lisp-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 07:19:38 -0000 --Apple-Mail-44-233546462 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The LISP folks doing implementations have agreed to converge on a new data-header format. We have agreed that mapping updates should be done in the control-plane. Having said that, we removed doing SMRs in the data-plane and we have agreed to not do map-versioning in the data- plane. Luigi and Damien have agreed to do research on this topic. Based on this, we have allocated an "R-bit for Research" where the fields in the LISP encapsulation header can be used for other purposes. See the html diff file enclosed for more details. So with this email, we are considered converged with respect to a mapping update solution. Based on feedback from my presentation at the LISP working group meeting in Stockholm, many felt that doing the TCP-counts locator reachability algorithm was too specific to the TCP protocol and should not be documented in the -04 draft. Many felt that RLOC-Probing was a necessary solution but should keep a careful eye on scalability and continue to test and research. So RLOC-Probing is documented in the -04 draft. See change-log below for changes proposed for draft -04 which reflects comments from the mailing list and tracker. I would like to have an open period for comments and responses before posting the -04. That way, there is some rough consensus on the changes. I'd like to have this open period from now through the weekend. Then I will post the -04 draft this coming Monday. Thanks, Dino/Dave/Darrel/Vince ------------------------------------------------------------------------------- Changes planned for draft-ietf-lisp-04.txt: * How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? * Add Fred Templin in ack section. * Add Margaret and Sam to the ack section for their great comments. * Say more about LAGs in the UDP section per Sam Hartman's comment. * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From the mailing list: You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums. * Margaret wants a reference to http://www.ietf.org/id/draft-eubanks- chimento-6man-00.txt. * Fix description in Map-Request section. Where we describe Map-Reply Record, change "R-bit" to "M-bit". * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. * Indicate SHA1 can be used as well for Map-Registers. * More Fred comments on MTU handling. * Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. * Margaret's comment on gleaning: The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail. * Add section on RLOC-probing per working group feedback. * Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. * Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. * Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. ------------------------------------------------------------------------------- --Apple-Mail-44-233546462 Content-Disposition: attachment; filename=rfcdiff-lisp-03-to-04.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-03-to-04.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: January 28, February 26, 2010                                      D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                         August 25, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-03.txt
                         draft-ietf-lisp-04.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 28, February 26, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 21
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 21
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 22
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 24
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 24
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 26
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 26
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 28
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 29
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 34
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 39
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 40
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 41
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 42
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 42
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 44
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 45
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 46
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 46
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 47
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 48
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 49
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 49
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 49
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 51
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 51
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 51
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 51
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 53
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 53
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 55
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 56
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 57
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 60
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 60
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 61
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 64
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 65

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the later, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the
   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [SHIM6]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:

   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and should not be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

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

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they staticly configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepend a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      staticly configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR
      prepends or an ETR strips.

   Address Family Indicator (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] for details.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepend LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets in flow through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either an TE-ETR within
   the ISP (along intra-ISP traffic engineered path) or in an TE-ETR
   within another ISP (an inter-ISP traffic engineered path, where an
   agreement to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively.

   o  Data Probes are used to solicit Map-Replies versus using Map-
      Requests.  And the Data Probes are sent on the underlying topology
      (the LISP 1.0 variant) but could also be sent over an alternative
      topology (the LISP 1.5 variant) as it would in [ALT].

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is used as the destination EID and the
       locally-assigned address of host1.abc.com is used as the source
       EID.  An IPv4 or IPv6 packet is built using the EIDs in the IPv4
       or IPv6 header and sent to the default router.

   2.  The default router is configured as an ITR.  The ITR must be able
       to map the EID destination to an RLOC of the ETR at the
       destination site.  The ITR prepends a LISP header to the packet,
       with one of its RLOCs as the source IPv4 or IPv6 address.  The
       destination EID from the original packet header is used as the
       destination IPv4 or IPv6 in the prepended LISP header.
       Subsequent packets, where the outer destination address is the
       destination EID will be sent until EID-to-RLOC mapping is
       learned.

   3.  In LISP 1, the packet is routed through the Internet as it is
       today.  In LISP 1.5, the packet is routed on a different topology
       which may have EID prefixes distributed and advertised in an
       aggregatable fashion.  In either case, the packet arrives at the
       ETR.  The router is configured to "punt" the packet to the
       router's processor.  See Section 7 for more details.  For LISP
       2.0 and 3.0, the behavior is not fully defined yet.

   4.  The LISP header is stripped so that the packet can be forwarded
       by the router control plane.  The router looks up the destination
       EID in the router's EID-to-RLOC database (not the cache, but the
       configured data structure of RLOCs).  An EID-to-RLOC Map-Reply
       message is originated by the ETR and is addressed to the source
       RLOC in the LISP header of the original packet (this is the ITR).
       The source RLOC of the Map-Reply is one of the ETR's RLOCs.

   5.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   6.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   7.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L / |                       Locator Reach Bits   |R|N|L|E| rflags|                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S \ |S|E| rsvd-flags|                  Nonce / |                       Locator Status Bits                     |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L / |                       Locator Reach Bits   |R|N|L|E| rflags|                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S \ |S|E| rsvd-flags|                  Nonce / |                       Locator Status Bits                     |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   IH Header:  is the inner header, preserved from the datagram received
      from the originating host.  The source and destination IP
      addresses are EIDs.

   OH Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0. 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field MUST MAY be transmitted as 0 zero by an ITR and ignored on
      receipt
      when received by an ETR MUST accept zero.  When an ITR transmits a
      non-zero value, an ETR MAY compute the ETR. checksum.  Note, even when
      the UDP checksum is transmitted as 0 zero an intervening NAT device
      can recalculate the checksum and rewrite the UDP checksum field to
      non-zero.  For
      performance reasons, the ETR MUST ignore the checksum and MUST not
      do a checksum computation.  See draft [UDP-TUNNELS] for details.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP
      headers are used.  The UDP header length is 8 bytes.  The LISP
      header length

   R: this is 8 bytes when no loc-reach-bit header extensions
      are used.

   LISP Locator Reach Bits:  in the LISP header are Research bit.  When this bit is set by an ITR to
      indicate to an ETR the reachability of 1, the Locators in N and L
      bits must be set to 0.

   L: this is the source
      site.  Each RLOC in a Map-Reply Locator-Status-Bits field enabled bit.  When this bit
      is assigned an ordinal value from
      0 set to n-1 (when there are n RLOCs 1, the Locator-Status-Bits in a mapping entry).  The Locator
      Reach Bits are numbered from 0 to n-1 from the right significant
      bit second 32-bits of the 32-bit field.
      LISP header are in use.  When a this bit is set to 1, the ITR is
      indicating to the ETR the RLOC associated with the R bit ordinal must be
      set to 0.

   N: this is
      reachable.  See Section 6.3 for details on how an ITR can
      determine other ITRs at the site are reachable. nonce-present bit.  When a site has
      multiple EID-prefixes which result in multiple mappings (where
      each could have a different locator-set), the Locator Reach Bits
      setting in an encapsulated packet MUST reflect this bit is set to 1, the mapping for
      low-order 24-bits of the
      EID-prefix that first 32-bits of the inner-header source EID address matches.

   S: LISP header contains
      a Nonce.  When this bit is set to 1, the Solicit-Map-Request (SMR) bit. R bit must be 0.  See
      section Section 6.5.2 6.3.1 for details.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1 and the R bit must be 0.  This bit should be
      ignored and has no meaning when the N bit is set to 0.  See
      section Section 6.3.1 for details.

   rsvd-flags:

   rflags:  this 6-bit 4-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR. ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.
      See section Section 6.3.1 for more details.  The nonce is also
      used when SMR-bit  When the E-bit is set to solicit clear but the other side to send N-bit
      is set, an ITR is echoing a Map-
      Request containing this nonce. previously requested echo-nonce.  See
      section Section 6.5.2 6.3.1 for more details.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The OH header Time to Live field (or Hop Limit field,

   LISP Locator Status Bits:  in case of
      IPv6) MUST be copied from the IH LISP header Time are set by an ITR to Live field.

   o  The OH header Type
      indicate to an ETR the up/down status of Service field (or the Traffic Class field, Locators in the case of IPv6) SHOULD be copied
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from the 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the right
      significant bit of the 32-bit field.  When a bit is set to 1, the
      ITR is indicating to the ETR the RLOC associated with the bit
      ordinal has up status.  See Section 6.3 for details on how an ITR
      can determine other ITRs at the site are reachable.  When a site
      has multiple EID-prefixes which result in multiple mappings (where
      each could have a different locator-set), the Locator Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The OH header Time to Live field (or Hop Limit field, in case of
      IPv6) MUST be copied from the IH header Time to Live field.

   o  The OH header Type of Service field (or the Traffic Class field,
      in the case of IPv6) SHOULD be copied from the IH header Type of
      Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:

   o  The new OH header Time to Live field SHOULD be copied from the
      stripped OH header Time to Live field.

   o  The new OH header Type of Service field SHOULD be copied from the
      stripped OH header Type of Service field (with one caveat, see
      below)..

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions reference below to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size of L bytes, it
   resolves the MTU issue by first splitting the original packet into 2
   equal-sized fragments.  A LISP header is then prepended to each
   fragment.  This will ensure that the new, encapsulated packets are of
   size (S/2 + H), which is always below the effective tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header the DF bit is
   always set to 0.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is describe as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 0, 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request and
   Map-Reply messages.  It MUST be checked on receipt and if the
   checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                        0    b'0000'
       LISP Map-Request:                1    b'0001'
       LISP Map-Reply:                  2    b'0010'
       LISP Map-Register:               3    b'0011'
       LISP-CONS Open Message:          8    b'1000'
       LISP-CONS Push-Add Message:      9    b'1001'
       LISP-CONS Push-Delete Message:   10   b'1010'
       LISP-CONS Unreachable Message    11   b'1011'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|           Reserved            | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |            ITR-AFI            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source EID Address  ...                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Originating ITR RLOC Address ...               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: Indicates that a Map-Request should be treated as a "piggyback"
      locator reachability probe.  The receiver should respond with a
      Map-Reply with the P bit set and the nonce copied from the Map-
      Request.  Details on this usage will be provided in a future
      version of this draft.  See section Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

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

   Record Count:  The number of records in this request message.  A
      record is comprised of the portion of the packet is labeled 'Rec'
      above and occurs the number of times equal to Record count.
      Compliant senders will always set the record count to 1.
      Complaint receivers should handle a record count of 1 or greater.
      Sending a count greater than 1 is used for future extensibility.

   Nonce:  A 4-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

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

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.

   Originating ITR RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in the address-family of this locator.

   EID mask-len:  Mask length for EID prefix.

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

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the R M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  In
   all cases, the UDP source port number for the Map-Request message is
   a randomly allocated 16-bit value and the UDP destination port number
   is set to the well-known destination port number 4342.  A successful
   Map-Reply updates the cached set of RLOCs associated with the EID
   prefix range.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4341 when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests
   are LISP encapsulated the same way from a Map-Server to an ETR.
   Details on encapsulated Map-Requests and Map-Resolvers can be found
   in [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|M|    Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: Indicates that the Map-Reply is in response to a "piggyback"
      locator reachability Map-Request.  The nonce field should contain
      a copy of the nonce value from the original Map-Request.  Details
      on this usage will be provided in a future version of this draft.  See
      section Section 6.3.2 for more details.

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

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 4-byte value set in a Data-Probe packet or a Map-Request
      that is echoed here in the Map-Reply.

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

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  The current assigned
      values are:

      (0) No action:  No action is being conveyed by the sender of the
         Map-Reply message.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Drop:  The packet is dropped silently.

      (3) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

   M: when this bit is set, the ITR or PTR that caches this mapping
      entry should consider the Map-Replier as one that is moving
      frequently and that checking for RLOC changes is in order.

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

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

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   Replies SHOULD be sent for an EID-prefix no more often than once per
   second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   The addresses for a encapsulated data packets or Map-Request message
   are swapped and used for sending the Map-Reply.  The UDP source and
   destination ports are swapped as well.  That is, the source port in
   the UDP header for the Map-Reply is set to the well-known UDP port
   number 4342.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey
   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   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.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator addresss. address.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in a UDP with a destination UDP port 4342 and a
   randomly selected UDP port number.  Before an IPv4 or IPv6 network
   layer header is prepended, an AH header is prepended to carry
   authentication information.  The format conforms to the IPsec
   specification [RFC2402].  The Map-Register message will use transport
   mode by setting the IP protocol number field or the IPv6 next-header
   field to 51.

   The AH header from [RFC2402] is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Header   |  Payload Len  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameters Index (SPI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number Field                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                Authentication Data (variable)                 |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Next Header field is set to UDP.  The SPI field is set to 0
   (since no Security Association or Key Exchange protocol is being
   used).  The Sequence Number is a randomly chosen value by the sender.
   The Authentication Data is 16 bytes and holds a MD5 SHA-1 or SHA-128
   HMAC.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|M|    Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: Set to 1 by an ETR which sends a Map-Register message requesting
      for the Map-Server to proxy Map-Reply.  The Map-Server will send
      non-authoritative Map-Replies on behalf of the ETR.  Details on
      this usage will be provided in a future version of this draft.

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

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  The Nonce field is set to 0 in Map-Register messages.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR must assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A gleaned map-cache entry is stored for a very short period of
      time, on the order of seconds to allow enough time to have it
      verified.  A gleaned entry is verified by sending a Map-Request to
      the locator address obtained from the outer IP header source
      address field of the gleaned packet.  Once the Map-Request is
      answered with a Map-Reply, the map-cache entry will have complete
      locator-set information for the EID-prefix.  The map-cache entry
      is stored for the time indicated from the Map-Reply TTL.  During
      this time, any subsequent packet received with a source EID that
      matches this EID-prefix, no longer needs to be gleaned.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The Map-Reply and the database mapping service does not
   provide any reachability status for Locators.  This is done outside
   of the mapping service.  See next section for details.

6.3.  Routing Locator Reachability

   There are 4 methods for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator reachability up/down status is determined by an ETR by examining the
       Loc-Reach-Bits
       Loc-Status-Bits from a LISP header of a encapsulated data packet
       which is provided by an ITR when an ITR encapsulates data.

   2.  Locator unreachability is determined by an ITR by receiving ICMP
       Network or Host Unreachable messages.

   3.  Locator unreachability can also be determined by an BGP-enabled
       ITR when there is no prefix matching a Locator address from the
       BGP RIB.

   4.  Locator unreachability is determined when a host sends an ICMP
       Port Unreachable message.  This occurs when an ITR may not use
       any methods of interworking. one which is describe in [INTERWORK]
       and the encapsulated data packet is received by a host at the
       destination non-LISP site.

   5.  Locator reachability is determined by receiving a Map-Reply
       message from a ETR's Locator address in response to a previously
       sent Map-Request.

   6.  Locator reachability can also be determined by receiving packets
       encapsulated by the ITR assigned to the locator address.

   When determining Locator up/down reachability by examining the Loc-Reach-Bits Loc-
   Status-Bits from the LISP encapsulate encapsulated data packet, an ETR will
   receive up to date status from the ITR closest to the Locators at the
   source site.  The ITRs at the source site can determine reachability
   when running their IGP at the site.  When the ITRs are deployed on CE
   routers, typically a default route is injected into the site's IGP
   from each of the ITRs.  If an ITR goes down, the CE-PE link goes
   down, or the PE router goes down, the CE router withdraws the default
   route.  This allows the other ITRs at the site to determine one of
   the Locators has gone unreachable.

   The Locators listed in a Map-Reply are numbered with ordinals 0 to
   n-1.  The Loc-Reach-Bits Loc-Status-Bits in a LISP Data Message are numbered from 0
   to n-1 starting with the least significant bit numbered as 0.  So,
   for example, if the ITR with locator listed as the 3rd Locator
   position in the Map-Reply goes down, all other ITRs at the site will
   have the 3rd bit from the right cleared (the bit that corresponds to
   ordinal 2).

   When an ETR decapsulates a packet, it will look for a change in the
   Loc-Reach-Bits
   Loc-Status-Bits value.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator that has just gone
   unreachable.  It can start using the Locator again when the bit that
   corresponds to the Locator goes from 0 to 1.  Loc-Reach-Bits  Loc-Status-Bits are
   associated with a locator-set per EID-prefix.  Therefore, when a
   locator becomes unreachable, the loc-reach-bit loc-status-bit that corresponds to
   that locator's position in the list returned by the last Map-Reply
   will be set to zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected a stub links into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Reach-Bits
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path assymetry. asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR should not
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow between a pair of locators, a
   simple mechanism called "nonce echoing" can be used to determine
   reachability between an ITR and ETR.  When an ITR wants to solicit a
   nonce echo, it sets the E-bit N and E bits and places a 24-bit nonce in the
   LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the E-bit N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-
   nonce-request echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not may not be the same device as
   an ITR which transmits traffic from that site or the site to site
   traffic is unidirectional so there is no ITR returning traffic.

   Note that other locator reachability mechanisms are being researched
   and can be can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The P-bit (Probe Bit) of the Map-Request and Map-
   Reply messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the P-bit set, it
   returns a Map-Reply with the P-bit set.  The source address of the
   Map-Reply is set from the destination address of the Map-Request and
   the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply should contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide RTT estimates between a pair
   of locators which can be useful for network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to compliment or even override obtain those benefits, especially if the Echo Nonce
   Algorithm.
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-reach-bits loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-reach-bit loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator address to 0 as well as setting the corresponding
   loc-reach-bit
   loc-status-bit to 0.  This forces ITRs with old or new mappings to
   avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-reach-bit loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational and the other a protocol mechanism.  The operational
   approach uses a clock sweep method.  The protocol approach uses the
   concept of Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in an encapsulated data packet
   (and a Map-Request message).  When an ETR at a remote site
   decapsulates a data packet that has the SMR bit set, it can tell that message.  An ITR
   or PTR will send a new Map-Request message is being solicited. when they receive an SMR message.
   Both the xTR that
   sends the SMR message sender and the site that acts on the SMR message MUST
   be rate-limited. Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ITRs ETRs at the site
       begin to set send Map-Requests with the SMR bit set for each locator
       in packets they encapsulate to each map-cache entry the sites
       they communicate with. ETR caches.

   2.  A remote xTR which decapsulates a packet with receives the SMR bit set message will schedule sending
       a Map-Request message to the source locator address of the encapsulated packet.  The SMR
       message.  A newly allocated random nonce in is selected and the Map-Request EID-
       prefix uses is the one copied from the nonce in the encapsulated data packet that has
       the SMR bit set. message.

   3.  The remote xTR retransmits the Map-Request slowly until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, records the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-reach-bits loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending packets
       with the SMR-bit set. SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing < attacks.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source source RLOC address of the encapsulated
   traceroute packet.  The ITR looks inside of the ICMP payload to
   inspect the traceroute source so it can return the ICMP message to
   the address of the traceroute client as well as retaining the core
   router IP address in the ICMP message.  This is so the traceroute
   client can display the core router address (the RLOC address) in the
   traceroute output.  The ETR returns its RLOC address and responds to
   the TTL decrement to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP to
   reduce the number of mapping changes required and to reduce the delay
   per mapping change.  Also IP mobility can be modified to require
   fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   An mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers
   can RPF to the ITR (the Locator address which is injected into core
   routing) rather than the host source address (the EID address which
   is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 4-byte Nonce field in the LISP encapsulation header.  The
   nonce, coupled with the ITR accepting only solicited Map-Replies goes
   a long way toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

13.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  This draft will be the draft for interoperable implementations to
       code against.  Interoperable implementations will be ready
       beginning of 2009.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.

   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and
        Andrew Partan continue to test all the features described above
        on a dual-stack infrastructure.

   6.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.

   7.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   8.   An public domain implementation of LISP is underway.  See
        [OPENLISP] for details.

   9.   We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   10.  A cisco IOS implementation is underway which currently supports
        IPv4 encapsulation and decapsulation features.

   11.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   12.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   13.  An experimental implementation has been written for three
        locator reachability algorithms.  One is called echo-noncing,
        which is documented in this specification.  The other two are
        called TCP-counts and RLOC-probing, which will be documented in
        future drafts.

   14.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.

14.  References

14.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

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

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

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

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

14.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt (work in progress), May 2009.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-00.txt (work in progress),
              January 2009.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt (work in progress),
              May 2009.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

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

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-01.txt (work in progress),
              May 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [SHIM6]    Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress), October 2006.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, and Isidor Kouvelas. Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, and Sam Hartman.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-44-233546462 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-44-233546462-- From arifumi@nttv6.net Wed Aug 26 02:03:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB933A69EB for ; Wed, 26 Aug 2009 02:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ngExoHa8Scl for ; Wed, 26 Aug 2009 02:03:48 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 290B73A68A1 for ; Wed, 26 Aug 2009 02:03:44 -0700 (PDT) Received: from [IPv6:2001:fa8:1000::f8bd:41ae:d1fa:1d12] ([IPv6:2001:fa8:1000:0:f8bd:41ae:d1fa:1d12]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n7Q93Pcm047289; Wed, 26 Aug 2009 18:03:25 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: David Meyer In-Reply-To: <20090824155328.GA17784@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 18:03:25 +0900 References: <20090824155328.GA17784@1-4-5.net> X-Mailer: Apple Mail (2.936) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 26 Aug 2009 18:03:26 +0900 (JST) Cc: lisp@ietf.org Subject: Re: [lisp] How to join the testbed X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 09:03:49 -0000 David, > Basically you need someting that can speak LISP. AFAIK > right now that is only Dino's implementation (there is an > openLISP implentation which runs on freeBSD, but my > understanding is that its a big behind the current set of > spects). > > Once you have something that can speak LISP, you can > splice on to an appropriate map-server. That means I need a box that runs NX-OS, and according to the following site NX-OS runs on several platforms. http://www.cisco.com/en/US/products/ps9372/index.html Unified data center operating system: NX-OS runs on the Cisco Nexus 7000 Series Switch, Nexus 5000 Series Switch, Cisco MDS Series Multilayer SAN Switch, and Cisco Nexus 1000V virtual switch for VMware ESX. LISP runs on either of the above mentioned platforms ? -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From hartmans@mit.edu Wed Aug 26 06:01:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278FF3A67F9 for ; Wed, 26 Aug 2009 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gcvZicevjQC for ; Wed, 26 Aug 2009 06:01:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7EB363A67F3 for ; Wed, 26 Aug 2009 06:01:46 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E33DA641DA; Wed, 26 Aug 2009 09:01:03 -0400 (EDT) To: Marshall Eubanks References: <2CD35D6F-6069-4F35-A378-9299BBF60319@lilacglade.org> <4A938B10.9090706@cisco.com> <0986B0C3-48D0-40EE-AF2D-E8925FBCD1B0@americafree.tv> From: Sam Hartman Date: Wed, 26 Aug 2009 09:01:03 -0400 In-Reply-To: <0986B0C3-48D0-40EE-AF2D-E8925FBCD1B0@americafree.tv> (Marshall Eubanks's message of "Tue\, 25 Aug 2009 10\:45\:29 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Checksum-related issues for the tracker X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 13:01:48 -0000 >>>>> "Marshall" == Marshall Eubanks writes: Marshall> Is there any operational experience with v6 LISP and zero UDP Marshall> checksums ? It's my personal opinion that there is no significant operational experience involving LISP interoperability where one of the implementations is a stock UDP stack. Someone could disagree with my definition of significant, stock or interoperability and come to a different conclusion. From mrw@sandstorm.net Wed Aug 26 09:02:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1768E3A70A6 for ; Wed, 26 Aug 2009 09:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyMhOcM-UOGN for ; Wed, 26 Aug 2009 09:02:00 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id E7D2B3A6F79 for ; Wed, 26 Aug 2009 09:01:59 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7QG1iFK055740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Aug 2009 12:01:44 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <7CAC7121-390F-4780-B790-246EFE013E5E@sandstorm.net> From: Margaret Wasserman To: Dino Farinacci In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 26 Aug 2009 12:01:43 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Andrew Partan , Noel Chiappa , lisp@ietf.org, "lispers list\)" Subject: Re: [lisp] Proposed changes to draft-ietf-lisp-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 16:02:01 -0000 Hi Dino, On Aug 26, 2009, at 3:19 AM, Dino Farinacci wrote: > > I would like to have an open period for comments and responses > before posting the -04. That way, there is some rough consensus on > the changes. I'd like to have this open period from now through the > weekend. Then I will post the -04 draft this coming Monday. IMO, this is not a reasonable period of time to review these changes, especially during prime vacation season. I am personally planning to be on vacation for the next two days, so I do not expect to have time to review these change until mid-next-week. In general, a 7-to-14 day review period would be more reasonable, depending on the extent of the changes and how extensively they have already been discussed on the list. Margaret From jari.arkko@piuha.net Wed Aug 26 09:35:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E9C3A70B5 for ; Wed, 26 Aug 2009 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncreGjHcHtg1 for ; Wed, 26 Aug 2009 09:35:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 044173A70B4 for ; Wed, 26 Aug 2009 09:35:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E0E0C19868A; Wed, 26 Aug 2009 19:35:30 +0300 (EEST) 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 AwwgmBrDVLXa; Wed, 26 Aug 2009 19:35:30 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5C9D31985F9; Wed, 26 Aug 2009 19:35:30 +0300 (EEST) Message-ID: <4A956451.3010801@piuha.net> Date: Wed, 26 Aug 2009 19:35:29 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dino Farinacci References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP Mobility Architecture X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 16:35:26 -0000 Dino, Sorry for the very late reply, but I am slowly working through the backlog of mail for my WGs after having returned to work... > I do agree with Jari's point. We have to be careful about > feature-creep in LISP. But from customers we have talked to, deploying > LISP *just to solve the route scalability problem* may not be > compelling enough. > > So we have to balance this view. But we can't have the cart come > before the horse. Exactly -- the cart before the horse part was what I was worried about. I fully understand the customer situation you explain above -- and that is something that we see with many technologies, not just with LISP. And yes, mobility and many other things can be very important. But back to the cart-before-the-horse issue. My goal with this working group is that it would figure out what the basics of LISP are, change what the collective expertise of IETF engineers say needs to change, figure out what the possible problem areas are, get code out that we can see if LISP actually works and whether the problems were real. We're not quite there yet. But when that work is complete THEN its time to look at the additional features. In other words, I'm trying to be the release manager for your first release of RFCs. I want you to focus on the basics first, and that's what the charter says. Get the foundation right, and you can build other stuff later. Jari From dino@cisco.com Wed Aug 26 12:29:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA333A6D40 for ; Wed, 26 Aug 2009 12:29:33 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydON7yiI1pCw for ; Wed, 26 Aug 2009 12:29:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BE94F3A6853 for ; Wed, 26 Aug 2009 12:29:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFMqlUqrR7PD/2dsb2JhbADAQIg5kDQFhBo X-IronPort-AV: E=Sophos;i="4.44,281,1249257600"; d="scan'208";a="91422281" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Aug 2009 19:29:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7QJTNiE031241; Wed, 26 Aug 2009 12:29:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7QJTNqD016854; Wed, 26 Aug 2009 19:29:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:29:23 -0700 Received: from [128.107.115.62] ([128.107.115.62]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:29:23 -0700 Message-Id: <73740BB1-5C85-4DD0-B0AF-68B20D990C92@cisco.com> From: Dino Farinacci To: Jari Arkko In-Reply-To: <4A956451.3010801@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 26 Aug 2009 12:29:26 -0700 References: <7070C816-A8C3-4D21-AFEA-82A70203E573@lilacglade.org> <08697F25-CB21-404D-8115-B8D61CC7B298@cisco.com> <4A956451.3010801@piuha.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 Aug 2009 19:29:23.0167 (UTC) FILETIME=[840FA6F0:01CA2683] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=834; t=1251314963; x=1252178963; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20Mobility=20Architecture |Sender:=20; bh=kRZ+GBeFG5EBcqVhPDfJY8mMSrYMy0vbITnEAsWtVWM=; b=cFoM8wD55XgHTaubEng4cnOe2RuDhh/k88T/thmY4JJcyCRg7e1pFqz7KF tldl4jVBhEtQSU5kXSAn21oR0xuqUVHVp83irS/24dUkODDNhzB0p5XvstxH e/EZyL8Q5b; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP Mobility Architecture X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 19:29:33 -0000 > But back to the cart-before-the-horse issue. My goal with this > working group is that it would figure out what the basics of LISP > are, change what the collective expertise of IETF engineers say > needs to change, figure out what the possible problem areas are, get > code out that we can see if LISP actually works and whether the > problems were real. We're not quite there yet. But when that work is > complete THEN its time to look at the additional features. Agree 100%. > In other words, I'm trying to be the release manager for your first > release of RFCs. I want you to focus on the basics first, and that's > what the charter says. Get the foundation right, and you can build > other stuff later. Agree and we do need a release manager, so thanks for taking on that role. Dino From dino@cisco.com Wed Aug 26 14:39:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04B63A6B39 for ; Wed, 26 Aug 2009 14:39:38 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyiXh0TEgKIQ for ; Wed, 26 Aug 2009 14:39:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EFD2E3A6A4A for ; Wed, 26 Aug 2009 14:39:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMpIlUqrR7PD/2dsb2JhbAC/Xog5kCUFhBo X-IronPort-AV: E=Sophos;i="4.44,282,1249257600"; d="scan'208";a="375967943" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2009 21:39:44 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7QLdiAe032081; Wed, 26 Aug 2009 14:39:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7QLdiWF004086; Wed, 26 Aug 2009 21:39:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 14:39:44 -0700 Received: from [128.107.115.62] ([128.107.115.62]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 14:39:44 -0700 Message-Id: From: Dino Farinacci To: Margaret Wasserman In-Reply-To: <7CAC7121-390F-4780-B790-246EFE013E5E@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 26 Aug 2009 14:39:44 -0700 References: <7CAC7121-390F-4780-B790-246EFE013E5E@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 26 Aug 2009 21:39:44.0111 (UTC) FILETIME=[B9B4FFF0:01CA2695] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=980; t=1251322784; x=1252186784; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Proposed=20changes=20to=20draf t-ietf-lisp-04.txt |Sender:=20; bh=Vun8RMLnT3kWk7M7mzb+t35KJOUNt/+JIiWAyZbrfgE=; b=Zyj/PPKmMgYqHPgoGIQ8/ik7riP5CpSwT7cGBgWYupBoqT93lpfUFssp2H wSMM8eNqDv9drDYVGOtCgRBzV+EWvAyTdxK1L1Vmgi/8JshKQn+d2+TdttyE EVfLKqWhUZ; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Andrew Partan , Noel Chiappa , lisp@ietf.org, "lispers list\)" Subject: Re: [lisp] Proposed changes to draft-ietf-lisp-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2009 21:39:39 -0000 > Hi Dino, > > On Aug 26, 2009, at 3:19 AM, Dino Farinacci wrote: >> >> I would like to have an open period for comments and responses >> before posting the -04. That way, there is some rough consensus on >> the changes. I'd like to have this open period from now through the >> weekend. Then I will post the -04 draft this coming Monday. > > IMO, this is not a reasonable period of time to review these > changes, especially during prime vacation season. I am personally > planning to be on vacation for the next two days, so I do not expect > to have time to review these change until mid-next-week. In > general, a 7-to-14 day review period would be more reasonable, > depending on the extent of the changes and how extensively they have > already been discussed on the list. > > Margaret I think this is a reasonable request. So let's say the deadline is Friday September 4th. That gives roughly 10 days of a review period. Dino From hartmans@mit.edu Thu Aug 27 05:35:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BAB3A6967 for ; Thu, 27 Aug 2009 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOfQpKs244-6 for ; Thu, 27 Aug 2009 05:35:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 459483A67E3 for ; Thu, 27 Aug 2009 05:35:06 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 98110641DA; Thu, 27 Aug 2009 08:35:04 -0400 (EDT) To: Dino Farinacci References: <7CAC7121-390F-4780-B790-246EFE013E5E@sandstorm.net> From: Sam Hartman Date: Thu, 27 Aug 2009 08:35:04 -0400 In-Reply-To: (Dino Farinacci's message of "Wed\, 26 Aug 2009 14\:39\:44 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "lispers list\)" , Andrew Partan , lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Proposed changes to draft-ietf-lisp-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 12:35:07 -0000 Dino, thanks for the proposed changes. I'm going to need to look through the changes and confirm that either we have previous agreement on the mailing list or that we've received sufficient positive support to any significant change during the comment period. I'll have to ask you to wait for my review before posting, but I also believe I can get that to you by September 4 so I don't slow you down. Thanks, - --Sam From hartmans@mit.edu Thu Aug 27 06:23:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A781E28C579 for ; Thu, 27 Aug 2009 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1WWz3Oz+V1j for ; Thu, 27 Aug 2009 06:23:50 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 192FD28C580 for ; Thu, 27 Aug 2009 06:22:58 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53CAF641DA; Thu, 27 Aug 2009 09:22:58 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 27 Aug 2009 09:22:58 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] [#15] reviewing reference categorization X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 13:23:50 -0000 I opened an issue this morning because I noticed that some of the references in draft-ietf-lisp are incorrectly categorized between informative and normative. I think the chairs should go through the references or find someone to go through the references and propose new categorization to the editors. While I never complain if someone does work for me, I don't think this issue is actionable by the editors in its current form. From hartmans@mit.edu Thu Aug 27 06:24:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2991C3A69E2 for ; Thu, 27 Aug 2009 06:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Y1gpYFqnyA for ; Thu, 27 Aug 2009 06:24:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7B0EE3A681D for ; Thu, 27 Aug 2009 06:24:12 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53AEA641DA; Thu, 27 Aug 2009 09:24:13 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 27 Aug 2009 09:24:13 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] #2, #3 blocked X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 13:24:13 -0000 I think issue #2 is blocked on me explaining some of the security requirement technical motivations rather than just giving a list of process requirements. I think Issue #3 is blocked on actually doing security analysis. From trac@tools.ietf.org Thu Aug 27 07:54:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB8228C612 for ; Thu, 27 Aug 2009 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVS+GeAqbvI6 for ; Thu, 27 Aug 2009 07:54:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 12C2B28C246 for ; Thu, 27 Aug 2009 07:53:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MggMC-0007FU-RV; Thu, 27 Aug 2009 07:53:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "lisp issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: lisp Date: Thu, 27 Aug 2009 14:53:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/16 Message-ID: <060.f7c6ffb908f8a2b4b682e313b91d2a15@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, lisp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: [lisp] #16: Map versioning discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com 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, 27 Aug 2009 14:54:09 -0000 #16: Map versioning discussion ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@mit.edu | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- draft-iannone-lisp-mapping-versioning-00 proposes introducing a map versioning field into LISP. Dino proposes to include text in lisp-04 that has been discussed with the authors of that draft. This issue tracks whether we have WG consensus to do that and if not may turn into an issue for the broder map versioning issues. -- Ticket URL: lisp LISP WG document issues From hartmans@mit.edu Thu Aug 27 07:56:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921D928C5AC for ; Thu, 27 Aug 2009 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+OFg1hOThoC for ; Thu, 27 Aug 2009 07:56:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id ED05828C51A for ; Thu, 27 Aug 2009 07:56:15 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3B68E641DA; Thu, 27 Aug 2009 10:56:16 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Thu, 27 Aug 2009 10:56:16 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] #16: map versioning resolution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 14:56:16 -0000 The chair would like to ask the authors of draft-iannone-lisp-mapping-versioning-00 and others involved in the discussion to comment on Dino's proposed changes for draft-ietf-lisp-04. In particular, do you prefer his proposal to your original proposal? If so, why? Comments from others on this issue would also be very useful. From hartmans@mit.edu Thu Aug 27 07:59:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DE23A6DB7 for ; Thu, 27 Aug 2009 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqNVWpEtFarK for ; Thu, 27 Aug 2009 07:59:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 18FDF3A63EC for ; Thu, 27 Aug 2009 07:58:03 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 76130641DA; Thu, 27 Aug 2009 10:58:03 -0400 (EDT) To: hartmans-ietf@mit.edu, lisp@ietf.org References: <060.f7c6ffb908f8a2b4b682e313b91d2a15@tools.ietf.org> From: Sam Hartman Date: Thu, 27 Aug 2009 10:58:03 -0400 In-Reply-To: <060.f7c6ffb908f8a2b4b682e313b91d2a15@tools.ietf.org> (lisp issue tracker's message of "Thu\, 27 Aug 2009 14\:53\:44 -0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [lisp] #16: Map versioning discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 14:59:03 -0000 I'm very confused why the lisp issue tracker failed to talk to us about issues #8-15 but now chats again. From dino@cisco.com Thu Aug 27 15:58:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B1B3A6EC9 for ; Thu, 27 Aug 2009 15:58:37 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWUuH6eukzEQ for ; Thu, 27 Aug 2009 15:58:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7D1933A7102 for ; Thu, 27 Aug 2009 15:57:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN+rlkqrR7PE/2dsb2JhbADAPIg+AZABBYQZilQ X-IronPort-AV: E=Sophos;i="4.44,288,1249257600"; d="scan'208";a="376841904" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2009 22:57:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7RMvnrP018570; Thu, 27 Aug 2009 15:57:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7RMvnj3016504; Thu, 27 Aug 2009 22:57:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 15:57:49 -0700 Received: from dhcp-171-71-55-195.cisco.com ([171.71.55.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 15:57:48 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 27 Aug 2009 15:57:49 -0700 References: <7CAC7121-390F-4780-B790-246EFE013E5E@sandstorm.net> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 27 Aug 2009 22:57:48.0950 (UTC) FILETIME=[CC807360:01CA2769] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=187; t=1251413869; x=1252277869; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Proposed=20changes=20to=20draf t-ietf-lisp-04.txt |Sender:=20; bh=t7kVmL1jESvwxJdwCw2zeUHkCebhgLpKrILNfftTXAM=; b=RGM6IPsR/bDPSufHqHxFxxXnaYcFDw9E8GSPZAvXF2nIrddQ25DqWDQmi+ ktlWHhKuy+W3lfhnIaxB9G326aVeUWPK9qr4awXl7R0LTPJdab0ZQ9q7BUkp S4lXFlaruF; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "lispers list\)" , Andrew Partan , lisp@ietf.org, Noel Chiappa , Margaret Wasserman Subject: Re: [lisp] Proposed changes to draft-ietf-lisp-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Aug 2009 22:58:37 -0000 > I'll have to ask you to wait for my review before posting, but I also > believe I can get that to you by September 4 so I don't slow you down. I will wait for your review. Dino From dino@cisco.com Mon Aug 31 11:02:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C85D28C45A for ; Mon, 31 Aug 2009 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I6FAUKGcDwp for ; Mon, 31 Aug 2009 11:02:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D563F28C444 for ; Mon, 31 Aug 2009 11:01:26 -0700 (PDT) X-Files: rfcdiff-lisp-03-to-04.html : 155807 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4GAPesm0qrR7MV/2dsb2JhbACCJTG/KIhBASqOVAWCMgEECIFbgVqJJg X-IronPort-AV: E=Sophos;i="4.44,306,1249257600"; d="html'217?scan'217,208,217";a="186659377" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2009 18:01:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7VI1YiB003197 for ; Mon, 31 Aug 2009 11:01:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7VI1YKN026634 for ; Mon, 31 Aug 2009 18:01:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:01:34 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:01:34 -0700 Message-Id: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-99-704070638 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 11:01:33 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 18:01:34.0284 (UTC) FILETIME=[13A0A8C0:01CA2A65] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=163447; t=1251741694; x=1252605694; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Deadline=20for=20proposed=20changes=20to=20draf t-ietf-lisp-04.txt=20is=20Friday=20Sep=204th |Sender:=20; bh=yoPmJ0USwOFEBwFsoJe76VBRsS9KadB5oWEnssHWGz4=; b=WxMGzDJSzy0BNr/qIl1EvOZYvtF5yrDl3EZ0IyJ0J7HQhLfrjltGIzmt79 SOJ6CMNh+6CtyfesSFDBBOPmLDWXs8kColRZ6tbgL1PiTzJ4We11L1gieR4a gmlP186Vq2jTs8BjwjotjU0JfqxPm5MJSp0REUaN1hTk/IvhCZDmg=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 18:02:26 -0000 --Apple-Mail-99-704070638 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Just a friendly reminder that the proposed changes to draft-ietf- lisp-04.txt is this Friday September 4th. Thank you to all who have sent us comments last week. For those of you who have not reviewed the diffs yet, you can look at the updated html diff file enclosed. The change-log of the proposed changes is also enclosed. Please note there are 6 additional change-log entries at the end reflecting comments we received last week. Thanks a lot, Dino/Dave/Darrel/Vince ------------------------------------------------------------------------------- Changes planned for draft-ietf-lisp-04.txt: * How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? * Add Fred Templin in ack section. * Add Margaret and Sam to the ack section for their great comments. * Say more about LAGs in the UDP section per Sam Hartman's comment. * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From the mailing list: You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums. * Margaret wants a reference to http://www.ietf.org/id/draft-eubanks- chimento-6man-00.txt. * Fix description in Map-Request section. Where we describe Map-Reply Record, change "R-bit" to "M-bit". * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. * Indicate SHA1 can be used as well for Map-Registers. * More Fred comments on MTU handling. * Isidor comment about specing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. * Margaret's comment on gleaning: The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail. * Add section on RLOC-probing per working group feedback. * Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. * Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. * Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. * Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map- cache corruption by a 3rd party. Comment from Pedro. * Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. * Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. ------------------------------------------------------------------------------- --Apple-Mail-99-704070638 Content-Disposition: attachment; filename=rfcdiff-lisp-03-to-04.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-03-to-04.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: January 28, March 4, 2010                                          D. Lewis
                                                           cisco Systems
                                                           July 27,
                                                         August 31, 2009

                 Locator/ID Separation Protocol (LISP)
                         draft-ietf-lisp-03.txt
                         draft-ietf-lisp-04.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 28, March 4, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This draft describes a simple, incremental, network-based protocol to
   implement separation of Internet addresses into Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  This mechanism requires no
   changes to host stacks and no major changes to existing database
   infrastructures.  The proposed protocol can be implemented in a
   relatively small number of routers.

   This proposal was stimulated by the problem statement effort at the
   Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
   place in October 2006.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  Tunneling Details  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 18
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 21
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 21
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 22
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 24
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 24
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 26
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 26
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 28
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 29
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 32
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 33
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 34
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 36
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 39
     6.4.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 39 40
     6.5.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 40 41
       6.5.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 40 42
       6.5.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 41 42
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 43 44
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 45
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 45 46
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 46
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 46 47
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 47 48
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 49
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 48 49
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 48 49
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 50 51
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 50 51
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 51
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 51
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 52 53
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 52 53
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 55
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 55 56
   13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 57
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 60
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 60
     14.2. Informative References . . . . . . . . . . . . . . . . . . 60 61
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 64
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 65

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many years of discussion about the current IP routing and addressing
   architecture have noted that its use of a single numbering space (the
   "IP address") for both host transport session identification and
   network routing creates scaling issues (see [CHIAPPA] and [RFC1498]).
   A number of scaling benefits would be realized by separating the
   current IP address into separate spaces for Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs); among them are:

   1.  Reduction of routing table size in the "default-free zone" (DFZ).
       Use of a separate numbering space for RLOCs will allow them to be
       assigned topologically (in today's Internet, RLOCs would be
       assigned by providers at client network attachment points),
       greatly improving aggregation and reducing the number of
       globally-visible, routable prefixes.

   2.  More cost-effective multihoming for sites that connect to
       different service providers where they can control their own
       policies for packet flow into the site without using extra
       routing table resources of core routers.

   3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

   4.  Traffic engineering capabilities that can be performed by network
       elements and do not depend on injecting additional state into the
       routing system.  This will fall out of the mechanism that is used
       to implement the EID/RLOC split (see Section 4).

   5.  Mobility without address changing.  Existing mobility mechanisms
       will be able to work in a locator/ID separation scenario.  It
       will be possible for a host (or a collection of hosts) to move to
       a different point in the network topology either retaining its
       home-based address or acquiring a new address based on the new
       network location.  A new network location could be a physically
       different point in the network topology or the same physical
       point of the topology with a different provider.

   This draft describes protocol mechanisms to achieve the desired
   functional separation.  For flexibility, the mechanism used for
   forwarding packets is decoupled from that used to determine EID to
   RLOC mappings.  This document covers the former.  For the later, see
   [CONS], [ALT], [EMACS], [RPMD], and [NERD].  This work is in response
   to and intended to address the problem statement that came out of the
   RAWS effort [RFC4984].

   The Routing and Addressing problem statement can be found in [RADIR].

   This draft focuses on a router-based solution.  Building the solution
   into the network will facilitate incremental deployment of the
   technology on the Internet.  Note that while the detailed protocol
   specification and examples in this document assume IP version 4
   (IPv4), there is nothing in the design that precludes use of the same
   techniques and mechanisms for IPv6.  It should be possible for IPv4
   packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
   RLOCs.

   Related work on host-based solutions is described in Shim6 [SHIM6]
   and HIP [RFC4423].  Related work on a router-based solution is
   described in [GSE].  This draft attempts to not compete or overlap
   with such solutions and the proposed protocol changes are expected to
   complement a host-based mechanism when Traffic Engineering
   functionality is desired.

   Some of the design goals of this proposal include:

   1.  Require no hardware or software changes to end-systems (hosts).

   2.  Minimize required changes to Internet infrastructure.

   3.  Be incrementally deployable.

   4.  Require no router hardware changes.

   5.  Minimize the number of routers which have to be modified.  In
       particular, most customer site routers and no core routers
       require changes.

   6.  Minimize router software changes in those routers which are
       affected.

   7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
       be performed.

   There are 4 variants of LISP, which differ along a spectrum of strong
   to weak dependence on the topological nature and possible need for
   routability of EIDs.  The variants are:

   LISP 1:  uses EIDs that are routable through the RLOC topology for
      bootstrapping EID-to-RLOC mappings.  [LISP1] This was intended as
      a prototyping mechanism for early protocol implementation.  It is
      now deprecated and should not be deployed.

   LISP 1.5:  uses EIDs that are routable for bootstrapping EID-to-RLOC
      mappings; such routing is via a separate topology.

   LISP 2:  uses EIDS that are not routable and EID-to-RLOC mappings are
      implemented within the DNS.  [LISP2]

   LISP 3:  uses non-routable EIDs that are used as lookup keys for a
      new EID-to-RLOC mapping database.  Use of Distributed Hash Tables
      [DHTs] [LISPDHT] to implement such a database would be an area to
      explore.  Other examples of new mapping database services are
      [CONS], [ALT], [RPMD], [NERD], and [APT].

   This document on LISP 1.5, and LISP 3 variants, both of which rely on
   a router-based distributed cache and database for EID-to-RLOC
   mappings.  The LISP 1.0 mechanism works but does not allow reduction
   of routing information in the default-free-zone of the Internet.  The
   LISP 2 mechanisms are put on hold and may never come to fruition
   since it is not architecturally pure to have routing depend on
   directory and directory depend on routing.  The LISP 3 mechanisms
   will be documented elsewhere but may use the control-plane options
   specified in this specification.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   an address block assigned from
      a pool where blocks are not associated with any particular
      location in the network (e.g. from a particular service provider),
      and is therefore not topologically aggregatable in the routing
      system.

   Provider Assigned (PA) Addresses:   a block of IP addresses that are
      assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider CIDR block and is aggregated into the larger block before
      being advertised into the global Internet.  Traditionally, IP
      multihoming has been implemented by each multi-homed site
      acquiring its own, globally-visible prefix.  LISP uses only
      topologically-assigned and aggregatable address blocks for RLOCs,
      eliminating this demonstrably non-scalable practice.

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

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   A power-of-2 block of EIDs which are allocated to a
      site by an address allocation authority.  EID-prefixes are
      associated with a set of RLOC addresses which make up a "database
      mapping".  EID-prefix allocations can be broken up into smaller
      blocks when an RLOC set is to be associated with the smaller EID-
      prefix.  A globally routed address block (whether PI or PA) is not
      an EID-prefix.  However, a globally routed address block may be
      removed from global routing and reused as an EID-prefix.  A site
      that receives an explicitly allocated EID-prefix may not use that
      EID-prefix as a globally routed prefix assigned to RLOCs.

   End-system:   is an IPv4 or IPv6 device that originates packets with
      a single IPv4 or IPv6 header.  The end-system supplies an EID
      value for the destination address field of the IP header when
      communicating globally (i.e. outside of its routing domain).  An
      end-system can be a host computer, a switch or router device, or
      any network appliance.

   Ingress Tunnel Router (ITR):   a router which accepts an IP packet
      with a single IP header (more precisely, an IP packet that does
      not contain a LISP header).  The router treats this "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      Note that this destination RLOC may be an intermediate, proxy
      device that has better knowledge of the EID-to-RLOC mapping closer
      to the destination EID.  In general, an ITR receives IP packets
      from site end-systems on one side and sends LISP-encapsulated IP
      packets toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   is an ITR that is deployed in a service provider network
      that prepends an additional LISP header for Traffic Engineering
      purposes.

   Egress Tunnel Router (ETR):   a router that accepts an IP packet
      where the destination address in the "outer" IP header is one of
      its own RLOCs.  The router strips the "outer" header and forwards
      the packet based on the next IP header found.  In general, an ETR
      receives LISP-encapsulated IP packets from the Internet on one
      side and sends decapsulated IP packets to site end-systems on the
      other side.  ETR functionality does not have to be limited to a
      router device.  A server host can be the endpoint of a LISP tunnel
      as well.

   TE-ETR:   is an ETR that is deployed in a service provider network
      that strips an outer LISP header for Traffic Engineering purposes.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality is at the CE
      router.

   EID-to-RLOC Cache:   a short-lived, on-demand table in an ITR that
      stores, tracks, and is responsible for timing-out and otherwise
      validating EID-to-RLOC mappings.  This cache is distinct from the
      full "database" of EID-to-RLOC mappings, it is dynamic, local to
      the ITR(s), and relatively small while the database is
      distributed, relatively static, and much more global in scope.

   EID-to-RLOC Database:   a global distributed database that contains
      all known EID-prefix to RLOC mappings.  Each potential ETR
      typically contains a small piece of the database: the EID-to-RLOC
      mappings for the EID prefixes "behind" the router.  These map to
      one of the router's own, globally-visible, IP addresses.

   Recursive Tunneling:   when a packet has more than one LISP IP
      header.  Additional layers of tunneling may be employed to
      implement traffic engineering or other re-routing as needed.  When
      this is done, an additional "outer" LISP header is added and the
      original RLOCs are preserved in the "inner" header.  Any
      references to tunnels in this specification refers to dynamic
      encapsulating tunnels and never are they staticly configured.

   Reencapsulating Tunnels:   when a packet has no more than one LISP IP
      header (two IP headers total) and when it needs to be diverted to
      new RLOC, an ETR can decapsulate the packet (remove the LISP
      header) and prepend a new tunnel header, with new RLOC, on to the
      packet.  Doing this allows a packet to be re-routed by the re-
      encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      staticly configured.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR
      prepends or an ETR strips.

   Address Family Indicator (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] for details.

   Negative Mapping Entry:   also known as a negative cache entry, is an
      EID-to-RLOC entry where an EID-prefix is advertised or stored with
      no RLOCs.  That is, the locator-set for the EID-to-RLOC entry is
      empty or has an encoded locator count of 0.  This type of entry
      could be used to describe a prefix from a non-LISP site, which is
      explicitly not in the mapping database.  There are a set of well
      defined actions that are encoded in a Negative Map-Reply.

   Data Probe:   a LISP-encapsulated data packet where the inner header
      destination address equals the outer header destination address
      used to trigger a Map-Reply by a decapsulating ETR.  In addition,
      the original packet is decapsulated and delivered to the
      destination host.  A Data Probe is used in some of the mapping
      database designs to "probe" or request a Map-Reply from an ETR; in
      other cases, Map-Requests are used.  See each mapping database
      design for details.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   This design introduces "Tunnel Routers", which prepend LISP headers
   on host-originated packets and strip them prior to final delivery to
   their destination.  The IP addresses in this "outer header" are
   RLOCs.  During end-to-end packet exchange between two Internet hosts,
   an ITR prepends a new LISP header to each packet and an egress tunnel
   router strips the new header.  The ITR performs EID-to-RLOC lookups
   to determine the routing path to the the ETR, which has the RLOC as
   one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is not
      dependent on the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a transit
   router (i.e.  TE-ITR) when re-routing of the path for a packet is
   desired.  An obvious instance of this would be an ISP router that
   needs to perform traffic engineering for packets in flow through its
   network.  In such a situation, termed Recursive Tunneling, an ISP
   transit acts as an additional ingress tunnel router and the RLOC it
   uses for the new prepended header would be either an TE-ETR within
   the ISP (along intra-ISP traffic engineered path) or in an TE-ETR
   within another ISP (an inter-ISP traffic engineered path, where an
   agreement to build such a path exists).

   This specification mandates that no more than two LISP headers get
   prepended to a packet.  This avoids excessive packet overhead as well
   as possible encapsulation loops.  It is believed two headers is
   sufficient, where the first prepended header is used at a site for
   Location/Identity separation and second prepended header is used
   inside a service provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively.

   o  Data Probes are used to solicit Map-Replies versus using Map-
      Requests.  And the Data Probes are sent on the underlying topology
      (the LISP 1.0 variant) but could also be sent over an alternative
      topology (the LISP 1.5 variant) as it would in [ALT].

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is used as the destination EID and the
       locally-assigned address of host1.abc.com is used as the source
       EID.  An IPv4 or IPv6 packet is built using the EIDs in the IPv4
       or IPv6 header and sent to the default router.

   2.  The default router is configured as an ITR.  The ITR must be able
       to map the EID destination to an RLOC of the ETR at the
       destination site.  The ITR prepends a LISP header to the packet,
       with one of its RLOCs as the source IPv4 or IPv6 address.  The
       destination EID from the original packet header is used as the
       destination IPv4 or IPv6 in the prepended LISP header.
       Subsequent packets, where the outer destination address is the
       destination EID will be sent until EID-to-RLOC mapping is
       learned.

   3.  In LISP 1, the packet is routed through the Internet as it is
       today.  In LISP 1.5, the packet is routed on a different topology
       which may have EID prefixes distributed and advertised in an
       aggregatable fashion.  In either case, the packet arrives at the
       ETR.  The router is configured to "punt" the packet to the
       router's processor.  See Section 7 for more details.  For LISP
       2.0 and 3.0, the behavior is not fully defined yet.

   4.  The LISP header is stripped so that the packet can be forwarded
       by the router control plane.  The router looks up the destination
       EID in the router's EID-to-RLOC database (not the cache, but the
       configured data structure of RLOCs).  An EID-to-RLOC Map-Reply
       message is originated by the ETR and is addressed to the source
       RLOC in the LISP header of the original packet (this is the ITR).
       The source RLOC of the Map-Reply is one of the ETR's RLOCs.

   5.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is put in the ITR's EID-to-
       RLOC mapping cache (this is the on-demand cache, the cache where
       entries time out due to inactivity).

   6.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note,
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   7.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to eliminate the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  Tunneling Details

   This section describes the LISP Data Message which defines the
   tunneling header used to encapsulate IPv4 and IPv6 packets which
   contain EID addresses.  Even though the following formats illustrate
   IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
   combinations are supported as well.

   Since additional tunnel headers are prepended, the packet becomes
   larger and in theory can exceed the MTU of any link traversed from
   the ITR to the ETR.  It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   Based on informal surveys of large ISP traffic patterns, it appears
   that most transit paths can accommodate a path MTU of at least 4470
   bytes.  The exceptions, in terms of data rate, number of hosts
   affected, or any other metric are expected to be vanishingly small.

   To address MTU concerns, mainly raised on the RRG mailing list, the
   LISP deployment process will include collecting data during its pilot
   phase to either verify or refute the assumption about minimum
   available MTU.  If the assumption proves true and transit networks
   with links limited to 1500 byte MTUs are corner cases, it would seem
   more cost-effective to either upgrade or modify the equipment in
   those transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.  If analysis
   during LISP pilot deployment reveals that the assumption of
   essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
   then LISP can be modified prior to protocol standardization to add
   support for one of the proposed fragmentation and reassembly schemes.
   Note that two simple existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L / |                       Locator Reach Bits   |R|N|L|E| rflags|                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S \ |S|E| rsvd-flags|                  Nonce / |                       Locator Status Bits                     |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L / |                       Locator Reach Bits   |R|N|L|E| rflags|                 Nonce                         |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S \ |S|E| rsvd-flags|                  Nonce / |                       Locator Status Bits                     |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   IH Header:  is the inner header, preserved from the datagram received
      from the originating host.  The source and destination IP
      addresses are EIDs.

   OH Header:  is the outer header prepended by an ITR.  The address
      fields contain RLOCs obtained from the ingress router's EID-to-
      RLOC cache.  The IP protocol number is "UDP (17)" from [RFC0768].
      The DF bit of the Flags field is set to 0. 0 when the method in
      Section 5.4.1 is used and set to 1 when the method in
      Section 5.4.2 is used.

   UDP Header:  contains a ITR selected source port when encapsulating a
      packet.  See Section 6.4 for details on the hash algorithm used
      select a source port based on the 5-tuple of the inner header.
      The destination port MUST be set to the well-known IANA assigned
      port value 4341.

   UDP Checksum:  this field MUST MAY be transmitted as 0 zero by an ITR and ignored on
      receipt
      when received by an ETR MUST accept zero.  When an ITR transmits a
      non-zero value, an ETR MAY compute the ETR. checksum.  Note, even when
      the UDP checksum is transmitted as 0 zero an intervening NAT device
      can recalculate the checksum and rewrite the UDP checksum field to
      non-zero.  For
      performance reasons, the ETR MUST ignore the checksum and MUST not
      do a checksum computation.  See draft [UDP-TUNNELS] for details.

   UDP Length:  for an IPv4 encapsulated packet, the inner header Total
      Length plus the UDP and LISP header lengths are used.  For an IPv6
      encapsulated packet, the inner header Payload Length plus the size
      of the IPv6 header (40 bytes) plus the size of the UDP and LISP
      headers are used.  The UDP header length is 8 bytes.  The LISP
      header length

   R: this is 8 bytes when no loc-reach-bit header extensions
      are used.

   LISP Locator Reach Bits:  in the LISP header are Research bit.  When this bit is set by an ITR to
      indicate to an ETR the reachability of 1, the Locators in N and L
      bits must be set to 0.

   L: this is the source
      site.  Each RLOC in a Map-Reply Locator-Status-Bits field enabled bit.  When this bit
      is assigned an ordinal value from
      0 set to n-1 (when there are n RLOCs 1, the Locator-Status-Bits in a mapping entry).  The Locator
      Reach Bits are numbered from 0 to n-1 from the right significant
      bit second 32-bits of the 32-bit field.
      LISP header are in use.  When a this bit is set to 1, the ITR is
      indicating to the ETR the RLOC associated with the R bit ordinal must be
      set to 0.

   N: this is
      reachable.  See Section 6.3 for details on how an ITR can
      determine other ITRs at the site are reachable. nonce-present bit.  When a site has
      multiple EID-prefixes which result in multiple mappings (where
      each could have a different locator-set), the Locator Reach Bits
      setting in an encapsulated packet MUST reflect this bit is set to 1, the mapping for
      low-order 24-bits of the
      EID-prefix that first 32-bits of the inner-header source EID address matches.

   S: LISP header contains
      a Nonce.  When this bit is set to 1, the Solicit-Map-Request (SMR) bit. R bit must be 0.  See
      section Section 6.5.2 6.3.1 for details.

   E: this is the echo-nonce-request bit.  When this bit is set to 1,
      the N bit must be 1 and the R bit must be 0.  This bit should be
      ignored and has no meaning when the N bit is set to 0.  See
      section Section 6.3.1 for details.

   rsvd-flags:

   rflags:  this 6-bit 4-bit field is reserved for future flag use.  It is set
      to 0 on transmit and ignored on receipt.

   LISP Nonce:  is a 24-bit value that is randomly generated by an ITR. ITR
      when the N-bit is set to 1.  The nonce is also used when the E-bit
      is set to request the nonce value to be echoed by the other side
      when packets are returned.
      See section Section 6.3.1 for more details.  The nonce is also
      used when SMR-bit  When the E-bit is set to solicit clear but the other side to send N-bit
      is set, an ITR is either echoing a Map-
      Request containing this previously requested echo-nonce
      or providing a random nonce.  See section Section 6.5.2 6.3.1 for more
      details.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The OH header Time to Live field (or Hop Limit field,

   LISP Locator Status Bits:  in case of
      IPv6) MUST be copied from the IH LISP header Time are set by an ITR to Live field.

   o  The OH header Type
      indicate to an ETR the up/down status of Service field (or the Traffic Class field, Locators in the case of IPv6) SHOULD be copied from the IH header Type of
      Service field (with one
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator Status Bits are numbered from 0 to n-1 from the right
      significant bit of the 32-bit field.  When a bit is set to 1, the
      ITR is indicating to the ETR the RLOC associated with the bit
      ordinal has up status.  See Section 6.3 for details on how an ITR
      can determine other ITRs at the site are reachable.  When a site
      has multiple EID-prefixes which result in multiple mappings (where
      each could have a different locator-set), the Locator Status Bits
      setting in an encapsulated packet MUST reflect the mapping for the
      EID-prefix that the inner-header source EID address matches.

   When doing Recursive Tunneling or ITR/PTR encapsulation:

   o  The OH header Time to Live field (or Hop Limit field, in case of
      IPv6) SHOULD be copied from the IH header Time to Live field.

   o  The OH header Type of Service field (or the Traffic Class field,
      in the case of IPv6) SHOULD be copied from the IH header Type of
      Service field (with one caveat, see below).

   When doing Re-encapsulated Tunneling:

   o  The new OH header Time to Live field SHOULD be copied from the
      stripped OH header Time to Live field.

   o  The new OH header Type of Service field SHOULD be copied from the
      stripped OH header Type of Service field (with one caveat, see
      below)..

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   In the event that the MTU issues mentioned above prove to be more
   serious than expected, this section proposes 2 simple mechanisms to
   deal with large packets.  One is stateless using IP fragmentation and
   the other is stateful using Path MTU Discovery [RFC1191].

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be decided as
   well since it is a local decision in the ITR regarding how to deal
   with MTU issues.  Sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions reference below to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would receive from a source inside of
       its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size of L bytes, it
   resolves the MTU issue by first splitting the original packet into 2
   equal-sized fragments.  A LISP header is then prepended to each
   fragment.  This will ensure that the new, encapsulated packets are of
   size (S/2 + H), which is always below the effective tunnel MTU.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header the DF bit is
   always set to 0.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is describe as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 0, 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types are used to retrieve EID-to-RLOC
   mappings:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request and
   Map-Reply messages.  It MUST be checked on receipt and if the
   checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] use TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                        0    b'0000'
       LISP Map-Request:                1    b'0001'
       LISP Map-Reply:                  2    b'0010'
       LISP Map-Register:               3    b'0011'
       LISP-CONS Open Message:          8    b'1000'
       LISP-CONS Push-Add Message:      9    b'1001'
       LISP-CONS Push-Delete Message:   10   b'1010'
       LISP-CONS Unreachable Message    11   b'1011'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|           Reserved            | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |            ITR-AFI            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source EID Address  ...                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Originating ITR RLOC Address ...               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: Indicates that a Map-Request should be treated as a "piggyback"
      locator reachability probe.  The receiver should respond with a
      Map-Reply with the P bit set and the nonce copied from the Map-
      Request.  Details on this usage will be provided in a future
      version of this draft.  See section Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.5.2 for details.

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

   Record Count:  The number of records in this request message.  A
      record is comprised of the portion of the packet is labeled 'Rec'
      above and occurs the number of times equal to Record count.
      Compliant senders will always set the record count to 1.
      Complaint receivers should handle a record count of 1 or greater.
      Sending a count greater than 1 is used for future extensibility.

   Nonce:  A 4-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

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

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.

   Originating ITR RLOC Address:  Used to give the ETR the option of
      returning a Map-Reply in the address-family of this locator.

   EID mask-len:  Mask length for EID prefix.

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

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the R M bit is set, this field is the size of
      the "Record" field in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the later 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  In
   all cases, the UDP source port number for the Map-Request message is
   a randomly allocated 16-bit value and the UDP destination port number
   is set to the well-known destination port number 4342.  A successful
   Map-Reply updates the cached set of RLOCs associated with the EID
   prefix range.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4341 when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests
   are LISP encapsulated the same way from a Map-Server to an ETR.
   Details on encapsulated Map-Requests and Map-Resolvers can be found
   in [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6

   When mapping data accompanies a Map-Request and a receiver is
   configured to accept and verify the mapping data, the verifying Map-
   Request can be addressed to the source (the locator address) of the
   Map-Request if it is in the locator-set of the stored map-cache
   entry.  If it is not, then the verifying Map-Request MUST be sent
   with an EID destination address to the mapping database system.
   Since the mapping database system is known to be secure, it will
   deliver the Map-Request to the authoritative source of the mapping
   data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P| |P|E|            Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|M|    Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: Indicates that the Map-Reply is in response to a "piggyback"
      locator reachability Map-Request.  The nonce field should contain
      a copy of the nonce value from the original Map-Request.  Details
      on this usage will be provided in a future version of  See
      section Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this draft. Map-Reply message is
      enabled for the Echo-Nonce locator reachability algorithm.  See
      Section 6.3.1 for more details.

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

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 4-byte value set in a Data-Probe packet or a Map-Request
      that is echoed here in the Map-Reply.

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

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  The current assigned
      values are:

      (0) No action:  No action is being conveyed by the sender of the
         Map-Reply message.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Drop:  The packet is dropped silently.

      (3) Send-Map-Request:  The packet invokes sending a Map-Request.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set by the ETR.  See [CONS] for TCP-based Map-Replies.

   M: when this bit is set, the ITR or PTR that caches this mapping
      entry should consider the Map-Replier as one that is moving
      frequently and that checking for RLOC changes is in order.

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

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

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a percentage of total unicast packets that match the
      mapping entry.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to load-split traffic.  See
      Section 6.4 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.  When
      a single RLOC exists in a mapping entry, the weight value MUST be
      set to 100 and ignored on receipt.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a percentage
      of total number of trees build to the source site identified by
      the EID-prefix.  If a non-zero weight value is used for any RLOC,
      then all RLOCs must use a non-zero weight value and then the sum
      of all weight values MUST equal 100.  If a zero value is used for
      any RLOC weight, then all weights MUST be zero and the receiver of
      the Map-Reply will decide how to distribute multicast state across
      ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   R: when this bit is set, the locator is known to be reachable from
      the Map-Reply sender's perspective.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR or router acting as a proxy replier for the
      EID-prefix.  Note that the destination RLOC address MAY be an
      anycast address.  A source RLOC can be an anycast address as well.
      The source or destination RLOC MUST NOT be the broadcast address
      (255.255.255.255 or any subnet broadcast address known to the
      router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field
      is optional and present when the UDP length indicates there is
      enough space in the packet to include it.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   When a Data Probe packet or a Map-Request triggers a Map-Reply to be
   sent, the RLOCs associated with the EID-prefix matched by the EID in
   the original packet destination IP address field will be returned.
   The RLOCs in the Map-Reply are the globally-routable IP addresses of
   the ETR but are not necessarily reachable; separate testing of
   reachability is required.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   Replies SHOULD be sent for an EID-prefix no more often than once per
   second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   The addresses for a encapsulated data packets or Map-Request message
   are swapped and used for sending the Map-Reply.  The UDP source and
   destination ports are swapped as well.  That is, the source port in
   the UDP header for the Map-Reply is set to the well-known UDP port
   number 4342.

   Map-Reply records can have an empty locator-set.  This type of a Map-
   Reply is called a Negative Map-Reply.  Negative Map-Replies convey
   special actions by the sender to the ITR or PTR which have solicited
   the Map-Reply.  There are two primary applications for Negative Map-
   Replies.  The first is for a Map-Resolver to instruct an ITR or PTR
   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.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator addresss. address.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in a UDP with a destination UDP port 4342 and a
   randomly selected UDP port number.  Before an IPv4 or IPv6 network
   layer header is prepended, an AH header is prepended to carry
   authentication information.  The format conforms to the IPsec
   specification [RFC2402]. [RFC4302].  The Map-Register message will use transport
   mode by setting the IP protocol number field or the IPv6 next-header
   field to 51.

   The AH header from [RFC2402] [RFC4302] is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Header   |  Payload Len  |          RESERVED             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Security Parameters Index (SPI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number Field                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                Authentication Data (variable)                 |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Next Header field is set to UDP.  The SPI field is set to 0
   (since no Security Association or Key Exchange protocol is being
   used).  The Sequence Number is a randomly chosen value by the sender.
   The Authentication Data is 16 bytes and holds a MD5 SHA-1 or SHA-128
   HMAC.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  |A| ACT  | ACT |A|M|    Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |           Reserved            |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |           Unused Flags      |R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: Set to 1 by an ETR which sends a Map-Register message requesting
      for the Map-Server to proxy Map-Reply.  The Map-Server will send
      non-authoritative Map-Replies on behalf of the ETR.  Details on
      this usage will be provided in a future version of this draft.

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

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  The Nonce field is set to 0 in Map-Register messages.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR must assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The Map-Reply and the database mapping service does not
   provide any reachability status for Locators.  This

   o  A gleaned map-cache entry is done outside stored for a very short period of the
      time, on the order of seconds to allow enough time to have it
      verified.  A gleaned entry is verified by sending a Map-Request to
      the source EID address obtained from the inner IP header source
      address field of the gleaned packet.  Once the Map-Request is
      answered with a Map-Reply, the map-cache entry will have complete
      locator-set information for the EID-prefix.  The map-cache entry
      is stored for the time indicated from the Map-Reply TTL.  During
      this time, any subsequent packet received with a source EID that
      matches this EID-prefix, no longer needs to be gleaned.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are considered
   reachable.  The Map-Reply and the database mapping service does not
   provide any reachability status for Locators.  This is done outside
   of the mapping service.  See next section for details.

6.3.  Routing Locator Reachability

   There are 4 methods for determining when a Locator is either
   reachable or has become unreachable:

   1.  Locator reachability up/down status is determined by an ETR by examining the
       Loc-Reach-Bits
       Loc-Status-Bits from a LISP header of a encapsulated data packet
       which is provided by an ITR when an ITR encapsulates data.

   2.  Locator unreachability is determined by an ITR by receiving ICMP
       Network or Host Unreachable messages.

   3.  Locator unreachability can also be determined by an BGP-enabled
       ITR when there is no prefix matching a Locator address from the
       BGP RIB.

   4.  Locator unreachability is determined when a host sends an ICMP
       Port Unreachable message.  This occurs when an ITR may not use
       any methods of interworking. one which is describe in [INTERWORK]
       and the encapsulated data packet is received by a host at the
       destination non-LISP site.

   5.  Locator reachability is determined by receiving a Map-Reply
       message from a ETR's Locator address in response to a previously
       sent Map-Request.

   6.  Locator reachability can also be determined by receiving packets
       encapsulated by the ITR assigned to the locator address.

   When determining Locator up/down reachability by examining the Loc-Reach-Bits Loc-
   Status-Bits from the LISP encapsulate encapsulated data packet, an ETR will
   receive up to date status from the ITR closest to the Locators at the
   source site.  The ITRs at the source site can determine reachability
   when running their IGP at the site.  When the ITRs are deployed on CE
   routers, typically a default route is injected into the site's IGP
   from each of the ITRs.  If an ITR goes down, the CE-PE link goes
   down, or the PE router goes down, the CE router withdraws the default
   route.  This allows the other ITRs at the site to determine one of
   the Locators has gone unreachable.

   The Locators listed in a Map-Reply are numbered with ordinals 0 to
   n-1.  The Loc-Reach-Bits Loc-Status-Bits in a LISP Data Message are numbered from 0
   to n-1 starting with the least significant bit numbered as 0.  So,
   for example, if the ITR with locator listed as the 3rd Locator
   position in the Map-Reply goes down, all other ITRs at the site will
   have the 3rd bit from the right cleared (the bit that corresponds to
   ordinal 2).

   When an ETR decapsulates a packet, it will look for a change in the
   Loc-Reach-Bits
   Loc-Status-Bits value.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to the Locator that has just gone
   unreachable.  It can start using the Locator again when the bit that
   corresponds to the Locator goes from 0 to 1.  Loc-Reach-Bits  Loc-Status-Bits are
   associated with a locator-set per EID-prefix.  Therefore, when a
   locator becomes unreachable, the loc-reach-bit loc-status-bit that corresponds to
   that locator's position in the list returned by the last Map-Reply
   will be set to zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected a stub links into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if
   a locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Reach-Bits
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path assymetry. asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR should not
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it must use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When there is bidirectional data flow between a pair of locators, a
   simple mechanism called "nonce echoing" can be used to determine
   reachability between an ITR and ETR.  When an ITR wants to solicit a
   nonce echo, it sets the E-bit N and E bits and places a 24-bit nonce in the
   LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the E-bit N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-
   nonce-request echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices must
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not may not be
   ETR receiving traffic at a site may not may not be the same device as
   an ITR which transmits traffic from that site or the site to site
   traffic is unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR should only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The P-bit (Probe Bit) of the Map-Request and Map-
   Reply messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR or PTR may include a mapping data
   record for its own database mapping information.

   When an ETR receives a Map-Request message with the P-bit set, it
   returns a Map-Reply with the P-bit set.  The source address of the
   Map-Reply is set from the destination address of the Map-Request and
   the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply should contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the same device as
   an ITR which transmits traffic from that site or PTR, which sent the site RLOC-probe to site
   traffic is unidirectional so get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is no ITR returning traffic.

   Note that other it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator reachability mechanisms are being researched
   and is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide RTT estimates between a pair
   of locators which can be useful for network management purposes as
   well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to compliment or even override obtain those benefits, especially if the Echo Nonce
   Algorithm.
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a random value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.5.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of who
   requested its mappings.  For scalability reasons, we want to maintain
   this approach but need to provide a way for ETRs change their
   mappings and inform the sites that are currently communicating with
   the ETR site using such mappings.

   When a locator record is added to the end of a locator-set, it is
   easy to update mappings.  We assume new mappings will maintain the
   same locator ordering as the old mapping but just have new locators
   appended to the end of the list.  So some ITRs can have a new mapping
   while other ITRs have only an old mapping that is used until they
   time out.  When an ITR has only an old mapping but detects bits set
   in the loc-reach-bits loc-status-bits that correspond to locators beyond the list it
   has cached, it simply ignores them.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-reach-bit loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator address to 0 as well as setting the corresponding
   loc-reach-bit
   loc-status-bit to 0.  This forces ITRs with old or new mappings to
   avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-reach-bit loc-status-bit settings can
   be efficiently packed.

   We propose here two approaches for locator-set compaction, one
   operational and the other a protocol mechanism.  The operational
   approach uses a clock sweep method.  The protocol approach uses the
   concept of Solicit-Map-Requests.

6.5.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.

6.5.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for xTRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries.  So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.
   The xTRs can locally decide the algorithm for how often and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set in an encapsulated data packet
   (and a Map-Request message).  When an ETR at a remote site
   decapsulates a data packet that has the and to how
   many sites it sends SMR messages.

   An SMR message is simply a bit set, it can tell that set in a new Map-Request message is being solicited. message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the xTR that
   sends the SMR message sender and the site that acts on the SMR message MUST
   be rate-limited. Map-Request responder must rate-limited
   these messages.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ITRs ETRs at the site
       begin to set send Map-Requests with the SMR bit set for each locator
       in packets they encapsulate to each map-cache entry the sites
       they communicate with. ETR caches.

   2.  A remote xTR which decapsulates a packet with receives the SMR bit set message will schedule sending
       a Map-Request message to the source locator address of the encapsulated packet.  The SMR
       message.  A newly allocated random nonce in is selected and the Map-Request EID-
       prefix uses is the one copied from the nonce in the encapsulated data packet that has
       the SMR bit set. message.

   3.  The remote xTR retransmits the Map-Request slowly until it gets a
       Map-Reply while continuing to use the cached mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message provided the Map-Request
       nonce matches the nonce from the SMR.  The Map-Reply messages
       SHOULD be rate limited.  This is important to avoid Map-Reply
       implosion.

   5.  The ETRs, at the site with the changed mapping, records the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-reach-bits loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending packets
       with the SMR-bit set. SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   The nonce MUST be carried from SMR packet, into the resultant Map-
   Request, and then into Map-Reply to reduce spoofing attacks.

   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request must be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is known to be secure, it will deliver the
   Map-Request to the authoritative source of the mapping data.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  By
   doing tunnel header prepending [RFC1955] and stripping instead of re-
   writing addresses, existing hardware can support the forwarding model
   with little or no modification.  Where modifications are required,
   they should be limited to re-programming existing hardware rather
   than requiring expensive design changes to hard-coded algorithms in
   silicon.

   A few implementation techniques can be used to incrementally
   implement LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  No changes to existing,
      deployed hardware should be needed to support this.

   o  On an ITR, prepending a new IP header is as simple as adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Many routers that support
      GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already
      support this action.

   o  When a received packet's outer destination address contains an EID
      which is not intended to be forwarded on the routable topology
      (i.e.  LISP 1.5), the source address of a data packet or the
      router interface with which the source is associated (the
      interface from which it was received) can be associated with a VRF
      (Virtual Routing/Forwarding), in which a different (i.e. non-
      congruent) topology can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.
   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.

   When deciding on centralized versus distributed caching, the
   following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will describe where tunnel routers can reside
   in the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers gives an ISP control
   over the location of the egress tunnel endpoints.  That is, the ISP
   can decide if the tunnel endpoints are in the destination site (in
   either CE routers or last-hop routers within a site) or at other PE
   edges.  The advantage of this case is that two or more tunnel headers
   can be avoided.  By having the PE be the first router on the path to
   encapsulate, it can choose a TE path first, and the ETR can
   decapsulate and re-encapsulate for a tunnel to the destination end
   site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source source RLOC address of the encapsulated
   traceroute packet.  The ITR looks inside of the ICMP payload to
   inspect the traceroute source so it can return the ICMP message to
   the address of the traceroute client as well as retaining the core
   router IP address in the ICMP message.  This is so the traceroute
   client can display the core router address (the RLOC address) in the
   traceroute output.  The ETR returns its RLOC address and responds to
   the TTL decrement to 0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Heuristics can be added to LISP to
   reduce the number of mapping changes required and to reduce the delay
   per mapping change.  Also IP mobility can be modified to require
   fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   An mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the the host built packet to flow into the core even
   if the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers
   can RPF to the ITR (the Locator address which is injected into core
   routing) rather than the host source address (the EID address which
   is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 4-byte Nonce field in the LISP encapsulation header.  The
   nonce, coupled with the ITR accepting only solicited Map-Replies goes
   a long way toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

13.  Prototype Plans and Status

   The operator community has requested that the IETF take a practical
   approach to solving the scaling problems associated with global
   routing state growth.  This document offers a simple solution which
   is intended for use in a pilot program to gain experience in working
   on this problem.

   The authors hope that publishing this specification will allow the
   rapid implementation of multiple vendor prototypes and deployment on
   a small scale.  Doing this will help the community:

   o  Decide whether a new EID-to-RLOC mapping database infrastructure
      is needed or if a simple, UDP-based, data-triggered approach is
      flexible and robust enough.

   o  Experiment with provider-independent assignment of EIDs while at
      the same time decreasing the size of DFZ routing tables through
      the use of topologically-aligned, provider-based RLOCs.

   o  Determine whether multiple levels of tunneling can be used by ISPs
      to achieve their Traffic Engineering goals while simultaneously
      removing the more specific routes currently injected into the
      global routing system for this purpose.

   o  Experiment with mobility to determine if both acceptable
      convergence and session continuity properties can be scalably
      implemented to support both individual device roaming and site
      service provider changes.

   Here is a rough set of milestones:

   1.  This draft will be the draft for interoperable implementations to
       code against.  Interoperable implementations will be ready
       beginning of 2009.

   2.  Continue pilot deployment using LISP-ALT as the database mapping
       mechanism.

   3.  Continue prototyping and studying other database lookup schemes,
       be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.

   4.  Implement the LISP Multicast draft [MLISP].

   5.  Implement the LISP Mobile Node draft [LISP-MN].

   6.  Research more on how policy affects what gets returned in a Map-
       Reply from an ETR.

   7.  Continue to experiment with mixed locator-sets to understand how
       LISP can help the IPv4 to IPv6 transition.

   8.  Add more robustness to locator reachability between LISP sites.

   As of this writing the following accomplishments have been achieved:

   1.   A unit- and system-tested software switching implementation has
        been completed on cisco NX-OS for this draft for both IPv4 and
        IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.

   2.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [ALT].

   3.   A unit- and system-tested software switching implementation on
        cisco NX-OS has been completed for draft [INTERWORK].  Support
        for IPv4 translation is provided and PTR support for IPv4 and
        IPv6 is provided.

   4.   The cisco NX-OS implementation supports an experimental
        mechanism for slow mobility.

   5.   Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and
        Andrew Partan continue to test all the features described above
        on a dual-stack infrastructure.

   6.   Darrel Lewis and Dave Meyer have deployed both LISP translation
        and LISP PTR support in the pilot network.  Point your browser
        to http://www.lisp4.net to see translation happening in action
        so your non-LISP site can access a web server in a LISP site.

   7.   Soon http://www.lisp6.net will work where your IPv6 LISP site
        can talk to a IPv6 web server in a LISP site by using mixed
        address-family based locators.

   8.   An public domain implementation of LISP is underway.  See
        [OPENLISP] for details.

   9.   We have deployed Map-Resolvers and Map-Servers on the LISP pilot
        network to gather experience with [LISP-MS].  The first layer of
        the architecture are the xTRs which use Map-Servers for EID-
        prefix registration and Map-Resolvers for EID-to-RLOC mapping
        resolution.  The second layer are the Map-Resolvers and Map-
        Servers which connect to the ALT BGP peering infrastructure.
        And the third layer are ALT-routers which aggregate EID-prefixes
        and forward Map-Requests.

   10.  A cisco IOS implementation is underway which currently supports
        IPv4 encapsulation and decapsulation features.

   11.  A LISP router based LIG implementation is supported, deployed,
        and used daily to debug and test the LISP pilot network.  See
        [LIG] for details.

   12.  A Linux implementation of LIG has been made available and
        supported by Dave Meyer.  It can be run on any Linux system
        which resides in either a LISP site or non-LISP site.  See [LIG]
        for details.  Public domain code can be downloaded from
        http://github.com/davidmeyer/lig/tree/master.

   13.  An experimental implementation has been written for three
        locator reachability algorithms.  One is called echo-noncing,
        which is documented in this specification.  The other two are
        called TCP-counts and RLOC-probing, which will be documented in
        future drafts.

   14.  The LISP pilot network has been converted from using MD5 HMAC
        authentication for Map-Register messages to SHA-1 HMAC
        authentication.  ETRs send with SHA-1 but Map-Servers can
        received from either for compatibility purposes.

   If interested in writing a LISP implementation, testing any of the
   LISP implementations, or want to be part of the LISP pilot program,
   please contact lisp@ietf.org.

14.  References

14.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

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

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

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

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

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

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

14.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt (work in progress), May 2009.

   [APT]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01.txt (work in progress), November 2007.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [DHTs]     Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
              Algorithms for DHTs: Some Open Questions", PDF
              file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [GSE]      "GSE - An Alternate Addressing Architecture for  IPv6",
              draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-00.txt (work in progress),
              January 2009.

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01.txt (work in progress),
              May 2009.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
              in progress), July 2009.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-01.txt
              draft-ietf-lisp-ms-02.txt (work in progress), May
              September 2009.

   [LISP1]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP1) [Routable  ID
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
              October 2006.

   [LISP2]    Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
              "Locator/ID Separation Protocol (LISP2) [DNS-based
              Version]",
              Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
              November 2006.

   [LISPDHT]  Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
              Towards a DHT to map identifiers onto locators",
              draft-mathy-lisp-dht-00.txt (work in progress),
              February 2008.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-01.txt (work in progress),
              May 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              April 2008.

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
              January 2009.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [SHIM6]    Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-06.txt (work in
              progress), October 2006.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"", draft-eubanks-chimento-6man-00.txt (work in
              progress), February 2009.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
   Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
   Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
   Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
   Gagliano, and Isidor Kouvelas. Kouvelas, Jesper Skriver, Fred Templin, Margaret
   Wasserman, and Sam Hartman.

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-99-704070638 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-99-704070638-- From hartmans@mit.edu Mon Aug 31 11:19:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0212828C458 for ; Mon, 31 Aug 2009 11:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBxKHLBNuuVv for ; Mon, 31 Aug 2009 11:19:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 36D9A28C435 for ; Mon, 31 Aug 2009 11:19:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9AF84641DA; Mon, 31 Aug 2009 14:19:37 -0400 (EDT) To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> From: Sam Hartman Date: Mon, 31 Aug 2009 14:19:37 -0400 In-Reply-To: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> (Dino Farinacci's message of "Mon\, 31 Aug 2009 11\:01\:33 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 18:19:29 -0000 Dino, the following entries reference comments I can't seem to find on the list. Can you point me to the list discussion involved? * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. * Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map- cache corruption by a 3rd party. Comment from Pedro. * Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the the ALT (or to the EID). * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. [I see my comment but not Brian's] * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. * Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. From dino@cisco.com Mon Aug 31 11:35:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC4628C4A2 for ; Mon, 31 Aug 2009 11:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5wno33F15HX for ; Mon, 31 Aug 2009 11:35:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AF27328C4A0 for ; Mon, 31 Aug 2009 11:35:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALS0m0qrR7MV/2dsb2JhbADCCohBAY8HBYQailk X-IronPort-AV: E=Sophos;i="4.44,306,1249257600"; d="scan'208";a="200379194" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 31 Aug 2009 18:35:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7VIZUiw015718; Mon, 31 Aug 2009 11:35:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VIZUeT005306; Mon, 31 Aug 2009 18:35:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:35:30 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 11:35:29 -0700 Message-Id: <9FD28265-5194-4630-AB14-AF901BFBBCBE@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 11:35:29 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 18:35:29.0910 (UTC) FILETIME=[D0F48960:01CA2A69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2853; t=1251743730; x=1252607730; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Deadline=20for=20proposed=20ch anges=20to=20draft-ietf-lisp-04.txt=20is=20=20Friday=20Sep=2 04th |Sender:=20; bh=ZvCDrfHZvuYT9GYdGx0pEvsmLNd+TVzoSPm3CIKCJF0=; b=WhGGDSXf4DfP0o4ByMg+kHosxaLj4Gjmiyig9HGTbRic3AxnTSY6WLBmoh 8BfdJdS+6DoQ+fipOQZsq7bLr1uwaIwNfuVJcFjr6MAM18BvlPMz4XeavqAt TXr0xiZWZWr7NS/GwqnYrrS0h/D45cSFf7uywnL/T8Z2+Cj7lkX3A=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 18:35:20 -0000 > Dino, the following entries reference comments I can't seem to find on > the list. Can you point me to the list discussion involved? There isn't any because the commenters choose to not use the list. The diff file should be able to explain why the changes were made. If people want to bring the changes up on the list, they should. This review period is to review the changes proposed and not the document per say. But I will reply to each item below to make things more clear. > * Clarify that when E-bit is 0, the nonce field can be an echoed nonce > or > a random nonce. Comment from Jesper. There are two uses for the nonce when the E-bit is 0. The first version of the proposed text only referred to using the nonce when it was being echoed as part of the Echo-Noncing locator reachability algorithm. But Echo-Noncing is not used, the nonce value is a random 24-bit number chosen by the encapsulator. > * Indicate when doing data-gleaning that a verifying Map-Request is > sent > to the source-EID of the gleaned data packet so we can avoid map- > cache > corruption by a 3rd party. Comment from Pedro. So a cache corruption problem can occur (as specified in the diff file) when a third-party uses its on address (which would pass uRPF on the path from itself to the guy it wants to attack) to a decapsulator that will send a verifying Map-Request to the outer source of the LISP encapsulated packet (the third party) which in turn can return a bogus Map-Reply which the decapsultor would cache. The verifying Map-Request needs to go to the authoritative ETRs for the site and sending the verifying Map-Request to an EID will cause it to go over the mapping database system which is secure. > * Indicate that a verifying Map-Request, for accepting mapping data, > should be > sent over the the ALT (or to the EID). Same as above but for the piggyback mapping data in Map-Request packets. > * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. You and a private email from Brian asked for the change. > [I see my comment but not Brian's] > > * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- > noncing. > Comment by Pedro and Dino. Previously enabling Echo-Noncing is an all-or-nothing deal. So this let's us incrementally deploy it so you know what ETRs can echo your nonce by looking at the E-bit in the Map-Reply. A really good idea by Pedro. > * Jesper made a comment to loosen the language about requiring the > copy of > inner TTL to outer TTL since the text to get mixed-AF traceroute to > work would > violate the "MUST" clause. Changed from MUST to SHOULD in section > 5.3. There is nothing more to say about this then what is said above. Are you okay with this now Sam? Dino From dino@cisco.com Mon Aug 31 12:33:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC83B3A6ED7 for ; Mon, 31 Aug 2009 12:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlxocw4TpBJN for ; Mon, 31 Aug 2009 12:33:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 823B43A6ECC for ; Mon, 31 Aug 2009 12:33:52 -0700 (PDT) X-Files: rcdiff-lisp-ms-01-to-02.html : 21499 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcHAJfBm0qrR7PD/2dsb2JhbACCJDK/NIhBAY8KBYQa X-IronPort-AV: E=Sophos;i="4.44,307,1249257600"; d="html'217?scan'217,208,217";a="200401394" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 Aug 2009 19:27:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7VJRWLZ005800 for ; Mon, 31 Aug 2009 12:27:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7VJRWea020051 for ; Mon, 31 Aug 2009 19:27:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:27:31 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:27:31 -0700 Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-105-709228018 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 12:27:31 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 19:27:31.0573 (UTC) FILETIME=[159C8250:01CA2A71] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22838; t=1251746852; x=1252610852; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Changes=20proposed=20to=20draft-ietf-lisp-ms-02 .txt |Sender:=20; bh=D2oOaBHEU/LrFViQFYK1S2fv5F4aqcpsHH9UfZHDmfU=; b=uGFqNalt7ml0/k+6qgR7UyMSIx0qtFzJKpanG6kZgm7s46scLqxVXCmNSN mt0617TVWaJBq5mobVZ7w7GQZLNLtZI1yoYGsj7xYf0Rc6tOmUfXX059HZly xOHNhfy6Gu; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] Changes proposed to draft-ietf-lisp-ms-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 19:33:54 -0000 --Apple-Mail-105-709228018 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit These are simple proposed changes to make the map-server spec consistent with the proposed changes to draft-ietf-lisp-04.txt. We'd like to have a deadline of Sep 4th for these changes too. It should take 5 minutes to review. The proposed changes are: o Don't refer to MD5 but do refer to SHA. o Shorten the Map-Register periodic interval based on better results we have seen on bringing up an ETR. Thanks, Dino/Vince --Apple-Mail-105-709228018 Content-Disposition: attachment; filename=rcdiff-lisp-ms-01-to-02.html Content-Type: text/html; x-unix-mode=0644; name="rcdiff-lisp-ms-01-to-02.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-ms-01.txt draft-ietf-lisp-ms-02.txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: November 27, 2009                                  May 26, March 1, 2010                                   August 28, 2009

                            LISP Map Server
                       draft-ietf-lisp-ms-01.txt
                       draft-ietf-lisp-ms-02.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on November 27, 2009. March 1, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This draft describes the LISP Map-Server (LISP-MS), a computing
   system which provides a simple LISP protocol interface as a "front
   end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping
   database and associated virtual network of LISP protocol elements.

   The purpose of the Map-Server is to simplify the implementation and
   operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel
   Routers (ETRs), the devices that implement the "edge" of the LISP
   infrastructure and which connect directly to LISP-capable Internet
   end sites.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Interactions With Other LISP Components  . . . . . . . . . . .  7
     5.1.  ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  7
     5.2.  ETR/Map-Server EID Prefix Registration . . . . . . . . . .  7
     5.3.  Map-Server Processing  . . . . . . . . . . . . . . . . . .  8
     5.4.  Map-Resolver Processing  . . . . . . . . . . . . . . . . .  8  9
       5.4.1.  Anycast Map-Resolver Operation . . . . . . . . . . . .  9 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11 12
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 14

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   LISP [LISP] specifies an architecture and mechanism for replacing the
   addresses currently used by IP with two separate name spaces: EIDs,
   used within sites, and RLOCs, used on the transit networks that make
   up the Internet infrastructure.  To achieve this separation, LISP
   defines protocol mechanisms for mapping from EIDs to RLOCs.  In
   addition, LISP assumes the existence of a database to store and
   propagate those mappings globally.  Several such databases have been
   proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+
   ALT [ALT], with LISP+ALT being the system that is currently being
   implemented and deployed on the pilot LISP network.

   There are two types of operation for a LISP Map-Server: as a Map-
   Resolver, which accepts Map-Requests from an ITR and "resolves" the
   EID-to-RLOC mapping using the distributed mapping database, and as a
   Map-Server, which learns authoratative EID-to-RLOC mappings from an
   ETR and publish them in the database.  A single device may implement
   one or both types of operation.

   Conceptually, LISP Map-Servers share some of the same basic
   configuration and maintenance properties as Domain Name System (DNS)
   [RFC1035] servers and caching resolvers.  With this in mind, this
   specification borrows familiar terminology (resolver and server) from
   the DNS specifications.

3.  Definition of Terms

   Map-Server:   a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoratative source (typically, an
      ETR, though static configuration or another out-of-band mechanism
      may be used).  A Map-Server publishes these mappings in the
      distributed mapping database.

   Map-Resolver:   a network infrastructure component which accepts LISP
      Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map-Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.

   Encapsulated Map-Request:   a LISP Map-Request with an additional
      LISP header prepended.  Sent to UDP destination port 4341.  The
      "outer" addresses are globally-routeable IP addresses, also known
      as RLOCs.  Used by an ITR when sending to a Map-Resolver and by a
      Map-Server when sending to an ETR.

   Negative Map-Reply:   a LISP Map-Reply that contains an empty
      locator-set.  Returned in response to a Map-Request of the
      destination EID does not exist in the mapping database.
      Typically, this means that the "EID" being requested is an IP
      address connected to a non-LISP site.

   Map-Register message:   a LISP message sent by an ETR to a Map-Server
      to register its associated EID prefixes.  In addition to the set
      of EID prefixes to register, the message includes one or more
      RLOCs to be be used by the Map-Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.

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

   A Map-Server is a device which publishes EID-prefix information on
   behalf of ETRs and connects to the LISP distributed mapping database
   system to help answer LISP Map-Requests seeking the RLOCs for those
   EID prefixes.  To publish its EID-prefixes, an ETR periodically sends
   Map-Register messages to the Map-Server.  A Map-Register message
   contains a list of EID-prefixes plus a set of RLOCs that can be used
   to reach the ETR when a Map-Server needs to forward a Map-Request to
   it.

   On the LISP pilot network, which is expected to be a model for
   deployment of LISP on the Internet, a Map-Server connects to LISP+ALT
   network and acts as a "last-hop" ALT router.  Intermediate ALT
   routers forward Map-Requests to the Map-Server that advertises a
   particular EID-prefix and the Map-Server forwards them to the owning
   ETR, which responds with Map-Reply messages.

   The LISP Map-Server design also includes the operation of a Map-
   Resolver, which receives Encapsulated Map-Requests from its client
   ITRs and uses the distributed mapping database system to find the
   appropriate ETR to answer those requests.  On the pilot network, a
   Map-Resolver acts as a "first-hop" ALT router.  It has GRE tunnels
   configured to other ALT routers and uses BGP to learn paths to ETRs
   for different prefixes in the LISP+ALT database.  The Map-Resolver
   uses this path information to forward Map-Requests over the ALT to
   the correct ETRs.  A Map-Resolver may operate in either a non-caching
   mode, where it simply de-capsulates and forwards the Encapsulated
   Map-Requests that it receives from ITRs, or in caching mode, where it
   saves information about those Map-Reqeusts, originates new Map-
   Requests to the correct ETR, accepts and caches the Map-Replies, and
   finally forwards the Map-Replies to the original ITRs.

   Note that a single device can implement the functions of both a Map-
   Server and a Map-Resolver.  As is the case with the DNS, however,
   operational simplicity argues for keeping those functions separate.

5.  Interactions With Other LISP Components

5.1.  ITR EID-to-RLOC Mapping Resolution

   An ITR is configured with the address of a Map-Resolver.  This
   address is a "locator" or RLOC in that it must be routeable on the
   underlying core network; it must not need to be resolved through LISP
   EID-to-RLOC mapping as that would introduce a circular dependancy.
   When using a Map-Resolver, an ITR does not need to connect to any
   other database mapping system.  In particular, the ITR need not
   connect to the LISP+ALT infrastructure or implement the BGP and GRE
   protocols that it uses.

   An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
   when it needs an EID-to-RLOC mapping that is not found in its local
   map-cache.  Using the Map-Resolver greatly reduces both the
   complexity of the ITR implementation the costs associated with its
   operation.

   In response to an Encapsulated Map-Request, the ITR can expect one of
   the following:

   o  A negative LISP Map-Reply if the Map-Resolver can determine that
      the requested EID does not exist.  The ITR saves EID prefix
      returned in the Map-Reply in its cache, marking it as non-LISP-
      capable and knows not to attempt LISP encapsulation for
      destinations matching it.

   o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map-Server answering on behalf of the ETR.  Note
      that the stateless nature of non-caching Map-Resolver forwarding
      means that the Map-Reply may not be from the Map-Resolver to which
      the Encapsulated Map-Request was sent unless the target Map-
      Resolver offers caching (Section 5.4).

   Note that an ITR may use a Map-Resolver while also participating in
   another mapping database mechanism.  For example, an ITR that runs
   LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver.
   When doing this, an ITR should prefer querying an ETR learned through
   the ALT network as LISP+ALT provides better information about the set
   of define EID prefixes.  Such a configuration is expected to be very
   rare, since there is little benefit to using a Map-Resolver if an ITR
   is already using a mapping database system.

5.2.  ETR/Map-Server EID Prefix Registration

   An ETR publishes its EID prefixes to on a Map-Server by sending LISP
   Map-Register messages.  The  A Map-Register message is authenticated using
   an IPSec Authentication Header (AH) as defined in [RFC2402], with MD5
   SHA-1 or SHA-128 as the authentication HMAC.  Prior to sending a Map-Register Map-
   Register message, the ETR and Map-Server must be configured with a
   secret shared-key.  In addition, a Map-Server will typically perform
   additional verification checks, such as matching any EID-prefix
   listed in a Map-Register message against a list of prefixes for which
   the ETR is known to be an authoritative source.

   Map-Register messages are sent periodically from an ETR to a Map-
   Server with a suggested interval between messages of one minute.  A
   Map-Server should time-out and remove an ETR's registration if it has
   not received a valid Map-Register message within the past three
   minutes.  When first contacting a Map-Server after restart or changes
   to its EID-to-RLOC database mappings, an ETR may initially send Map-
   Register messages at an increased frequency, up to one every 20
   seconds.  This "quick registration" period is limited to five minutes
   in duration.

   An ETR which uses a Map-Server to publish its EID-to-RLOC mappings
   does not need to participate further in the mapping database
   protocol(s).  On the pilot network, for example, this means that the
   ETR does not need to implement GRE or BGP, which greatly simplifies
   its configuration and reduces its cost of operation.

   Note that use of a Map-Server does not preclude an ETR from also
   connecting to the mapping database (i.e. it could also connect to the
   LISP+ALT network) but doing so doesn't seem particularly useful as
   the whole purpose of using a Map-Server is to avoid the complexity of
   the mapping database protocols.

5.3.  Map-Server Processing

   The operation of a Map-Server, once it has EID-prefixes registered by
   its client ETRs, is quite simple.  In response to a Map-Request
   (received over the ALT on the pilot network), the Map-Server verifies
   that the destination EID matches an EID-prefix for which it has one
   or more registered ETRs, then re-encapsulates and forwards the now-
   Encapsulated Map-Reqeust to a matching ETR.  It does not otherwise
   alter the Map-Request so any Map-Reply sent by the ETR is returned to
   the RLOC in the Map-Request, not to the Map-Server.  Unless also
   acting as a Map-Resolver, a Map-Server should never receive Map-
   Replies; any such messages should be discarded without response,
   perhaps accompanied by logging of a diagnostic message if the rate of
   Map-Replies is suggestive of malicious traffic.

5.4.  Map-Resolver Processing

   In response to an Encapsulated Map-Request, a Map-Resolver de-
   capsulates the message then checks its local database of mapping
   entries (statically configured, cached, or learned from associated
   ETRs).  If it finds a matching entry, it returns a non-authoratative
   LISP Map-Reply with the known mapping.

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the requested IP address does not match an EID-prefix
   in the mapping database, it immediately returns a negative LISP Map-
   Reply, one which contains an EID prefix and an empty locator-set.  To
   minimize the number of negative cache entries needed by an ITR, the
   Map-Resolver should return the least-specific prefix which both
   matches the original query and does not match any EID-prefix known to
   exist in the LISP-capable infrastructure.

   If the Map-Resolver does not have sufficient information to know
   whether the EID exists, it needs to forward the Map-Request to
   another device which has more information about the EID being
   requested.  This is done in one of two ways:

   1.  A non-caching Map-Resolver simply forwards the unencapsulated
       Map-Request, with the original ITR RLOC as the source, on to the
       distributed mapping database.  On the pilot network, the Map-
       Resolver is connected to the ALT network and sends the Map-
       Request to the next ALT hop learned from its ALT BGP neighbors.
       The Map-Resolver does not send any response to the ITR; since the
       source RLOC is that of the ITR, the ETR or Map-Server which
       receives the Map-Request over the ALT and responds will do so
       directly to the ITR.

   2.  A caching Map-Resolver queues information from the Encapsulated
       Map-Request, including the ITR RLOC and the original nonce.  It
       then modifies the Map-Request to use its own RLOC, generates a
       "local nonce" (which is also saved in the request queue entry),
       and forwards the Map-Request as above.  When the Map-Resolver
       receives a Map-Reply, it looks in its request queue to match the
       reply nonce to a "local nonce" entry then de-queues the entry and
       uses the saved original nonce and ITR RLOC to re-write those
       fields in the Map-Reply before sending to the ITR.  The request
       queue entry is also deleted and the mapping entries from the Map-
       Reply are saved in the Map-Resolver's cache.

5.4.1.  Anycast Map-Resolver Operation

   A Map-Resolver can be set up to use "anycast", where where the same
   address is assigned to multiple Map-Resolvers and is propagated
   through IGP routing, to facilitate the use of a topologically-close
   Map-Resolver each ITR.  Note that Map-Server associations with ETRs
   should NOT use anycast addresses as doing so could cause
   unpredictable forwarding of Map-Requests to the ETRs.

6.  Security Considerations

   Using the 2-way nonce exchange documented in [LISP] can be used to
   avoid ITR spoofing attacks.

   To publish an authoratative EID-to-RLOC mapping, an ETR uses the
   IPsec AH to authenticate itself to a Map-Server.  A pair-wise shared
   key is used with MD5. SHA-1 or SHA-128.  A key-chaining scheme may also be
   employed to facilitate re-keying as needed.  ESP is not used, since
   the mapping data is considered to be public and does not need to be
   encrypted for transport.

7.  References

7.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

7.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-01.txt (work in progress), March 2009.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-00.txt
              draft-ietf-lisp-04.txt (work in progress) (work in
              progress), May September 2009.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-04.txt (work in progress),
              January 2008.

Appendix A.  Acknowledgments

   The authors would also like to thank the operational community for
   feedback on the previous mapping database mechanisms.

   Special thanks are due to Noel Chiappa for his extensive work on
   caching with LISP-CONS, some of which will be used by Map-Resolvers.

Authors' Addresses

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino   Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com
--Apple-Mail-105-709228018 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-105-709228018-- From jmh@joelhalpern.com Mon Aug 31 14:02:56 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0405A3A67E9 for ; Mon, 31 Aug 2009 14:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4uGeLNylxCH for ; Mon, 31 Aug 2009 14:02:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 73D8E28C4B3 for ; Mon, 31 Aug 2009 14:02:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7E3B3438012; Mon, 31 Aug 2009 14:02:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0D5FC437E53; Mon, 31 Aug 2009 14:02:15 -0700 (PDT) Message-ID: <4A9C3A57.2010501@joelhalpern.com> Date: Mon, 31 Aug 2009 17:02:15 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci , "lisp@ietf.org" References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> In-Reply-To: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Suggested UDP checksum text X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:02:56 -0000 I think the wordsmithing on the UDP checksum got tangled up. Whenever you get to making a revision, assuming that the WG stays with the intent of what you have written (which seems like a good choice to me), I would suggest: UDP Checksum: this field MAY be set to 0 by an ITR on transmission. Alternatively, an ITR MAY compute and store a valid UDP checksum in this field during transmission. Upon receipt, and ETR MUST accept a value of 0 as valid for this field, and consider the UDP packet valid. If an ETR receives a non-zero value in the checksum, field it MAY compute and validate the UDP checksum for the packet. If it chooses to do so, it is expected to discard UDP packets with invalid non-zero checksums. Then include the note text you already have. Does that make sense? Saying "When an ITR transmits...an ETR may compute is confusing. It is particularly confusing since the note indicates that the ETR can not tell whether the ITR or someone else filled in the checksum field with a non-zero value. Yours, Joel Dino Farinacci wrote: > Just a friendly reminder that the proposed changes to > draft-ietf-lisp-04.txt is this Friday September 4th. > > Thank you to all who have sent us comments last week. For those of you > who have not reviewed the diffs yet, you can look at the updated html > diff file enclosed. > > The change-log of the proposed changes is also enclosed. Please note > there are 6 additional change-log entries at the end reflecting comments > we received last week. > > Thanks a lot, > Dino/Dave/Darrel/Vince > > ------------------------------------------------------------------------------- > > > Changes planned for draft-ietf-lisp-04.txt: > > * How do deal with record count greater than 1 for a Map-Request. Damien > and > Joel comment. Joel suggests: > > 1) Specify that senders compliant with the current document will > always set the count to 1, and note that the count is included for > future extensibility. > > 2) Specify what a receiver compliant with the draft should do if it > receives a request with a count greater than 1. Presumably, it should > send some error back? > > * Add Fred Templin in ack section. > > * Add Margaret and Sam to the ack section for their great comments. > > * Say more about LAGs in the UDP section per Sam Hartman's comment. > > * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From > the mailing list: > > You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST > accept a 0 checksum and MAY ignore the checksum completely. And of > course we'd need to confirm that can actually be implemented. In > particular, hardware that verifies UDP checksums on receive needs to > be checked to make sure it permits 0 checksums. > > * Margaret wants a reference to http://www.ietf.org/id/draft-eubanks- > chimento-6man-00.txt. > > * Fix description in Map-Request section. Where we describe Map-Reply > Record, > change "R-bit" to "M-bit". > > * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs > but often enough to get mapping updates. > > * Indicate SHA1 can be used as well for Map-Registers. > > * More Fred comments on MTU handling. > > * Isidor comment about specing better periodic Map-Registers. Will be fixed > in draft-ietf-lisp-ms-02.txt. > > * Margaret's comment on gleaning: > > The current specification does not make it clear how long gleaned map > entries should be retained in the cache, nor does it make it clear > how/ when they will be validated. The LISP spec should, at the very > least, include a (short) default lifetime for gleaned entries, > require that they be validated within a short period of time, and > state that a new gleaned entry should never overwrite an entry that > was obtained from the mapping system. The security implications of > storing "gleaned" entries should also be explored in detail. > > * Add section on RLOC-probing per working group feedback. > > * Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. > > * Remove SMR-bit from data-plane. Dino prefers to have it in the control > plane only. > > * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields > can be turned off and used for another future purpose. For Luigi et al > versioning convergence. > > * Add a N-bit to the data header suggested by Noel. Then the nonce field > could > be used when N is not 1. > > * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or > a random nonce. Comment from Jesper. > > * Indicate when doing data-gleaning that a verifying Map-Request is sent > to the source-EID of the gleaned data packet so we can avoid map-cache > corruption by a 3rd party. Comment from Pedro. > > * Indicate that a verifying Map-Request, for accepting mapping data, > should be > sent over the the ALT (or to the EID). > > * Reference IPsec RFC 4302. Comment from Sam and Brian Weis. > > * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-noncing. > Comment by Pedro and Dino. > > * Jesper made a comment to loosen the language about requiring the copy of > inner TTL to outer TTL since the text to get mixed-AF traceroute to > work would > violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. > > ------------------------------------------------------------------------------- > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Mon Aug 31 14:04:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF963A6B88 for ; Mon, 31 Aug 2009 14:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAHCP32T5Lq9 for ; Mon, 31 Aug 2009 14:04:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4CE8D3A6AB6 for ; Mon, 31 Aug 2009 14:04:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 452CE437E53; Mon, 31 Aug 2009 14:04:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D521A437E4A; Mon, 31 Aug 2009 14:04:58 -0700 (PDT) Message-ID: <4A9C3AFA.8060908@joelhalpern.com> Date: Mon, 31 Aug 2009 17:04:58 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> In-Reply-To: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Meanign of R bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:04:48 -0000 What is supposed to happen if an ETR receives a packet with an R bit set to 1, and the N and L bits set to some combination other than 00? Is that an error? I would think it would make more sense to state that if the R bit is set, the N and L bits are considered reserved, meaning that they must be set to 0 on transmission, and ignored upon reception. That leaves us free to assign a meaning to the R bit, and decide when we do so how to use the other two bits. Yours, Joel From jmh@joelhalpern.com Mon Aug 31 14:22:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A182428C246 for ; Mon, 31 Aug 2009 14:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEMW8opWM6HY for ; Mon, 31 Aug 2009 14:22:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5899028C1D5 for ; Mon, 31 Aug 2009 14:22:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 729F943068C; Mon, 31 Aug 2009 14:22:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0BADF430687; Mon, 31 Aug 2009 14:22:57 -0700 (PDT) Message-ID: <4A9C3F31.20506@joelhalpern.com> Date: Mon, 31 Aug 2009 17:22:57 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> In-Reply-To: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:22:47 -0000 In the map reply, I am not sure I follow the reasoning for the "M" bit. At a guess, it is intended for mobility cases. As far as I can tell, it does not help. If the sender of the mapping data wants the receiver to validate the data frequently, then the sender should use a short ttl. Yours, Joel From dino@cisco.com Mon Aug 31 14:47:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501EA3A6B1E for ; Mon, 31 Aug 2009 14:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjMOosMC96OL for ; Mon, 31 Aug 2009 14:47:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 694153A6C2D for ; Mon, 31 Aug 2009 14:47:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALPhm0qrR7O6/2dsb2JhbADCGYhBAY8hBYI/gVs X-IronPort-AV: E=Sophos;i="4.44,307,1249257600"; d="scan'208";a="92298267" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2009 21:47:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7VLlhdt013650; Mon, 31 Aug 2009 14:47:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VLlhPl017635; Mon, 31 Aug 2009 21:47:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 14:47:36 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 14:47:35 -0700 Message-Id: <04DC887D-C635-4D58-9E93-4959148B4480@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C3A57.2010501@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 14:47:35 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3A57.2010501@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 21:47:35.0950 (UTC) FILETIME=[A702AAE0:01CA2A84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1503; t=1251755263; x=1252619263; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Suggested=20UDP=20checksum=20t ext |Sender:=20; bh=82UOu9s85UJq4re78gT6sqCm7PuxIhQKJISWxwRNwdk=; b=aioyDPq5Ynz0548LnJ1wmar9XjghyZG22tC9XwsJt2nOo6KQFImU5TMBk4 vzXLkHLg9+CdwGX5ffQVHBcjRWPnMBDeP/HIoU+P9rt+AQvE3h6p0KXPXMjz Hckcc4Vglk; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "lisp@ietf.org" Subject: Re: [lisp] Suggested UDP checksum text X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:47:33 -0000 > UDP Checksum: this field MAY be set to 0 by an ITR on transmission. > Alternatively, an ITR MAY compute and store a valid UDP checksum > in this field during transmission. Upon receipt, and ETR MUST > accept a value of 0 as valid for this field, and consider the UDP > packet valid. If an ETR receives a non-zero value in the > checksum, field it MAY compute and validate the UDP checksum for > the packet. If it chooses to do so, it is expected to discard > UDP packets with invalid non-zero checksums. There are a couple of problems with your text: (1) Valid does provide any value to the description, we should say accept and continue processing the packet or say "do not drop it". (2) If an ETR does choose to compute the checksum to validate it and it fails the checksum check, it must drop the packet. How about this text: UDP Checksum: this field MAY be transmitted as zero by an ITR and when received by an ETR, MUST accept the packet for forwarding. When an ITR transmits a non-zero value, an ETR MAY verify the checksum value. If the checksum is verified, the packet is accepted for forwarding, otherwise, it is silently dropped. Note, even when the UDP checksum is transmitted as zero an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. See draft [UDP-TUNNELS] for details. Sound better and more specific? Dino From dino@cisco.com Mon Aug 31 14:52:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777C93A6EA3 for ; Mon, 31 Aug 2009 14:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdBiWJS-zUMa for ; Mon, 31 Aug 2009 14:52:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9A56C3A6BF0 for ; Mon, 31 Aug 2009 14:52:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOrim0qrR7O6/2dsb2JhbADCFYhBAY8jBYQa X-IronPort-AV: E=Sophos;i="4.44,307,1249257600"; d="scan'208";a="92299856" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2009 21:52:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7VLqbqS021533; Mon, 31 Aug 2009 14:52:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VLqbDh022249; Mon, 31 Aug 2009 21:52:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 14:52:36 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 14:52:36 -0700 Message-Id: <64D637CF-771E-465E-9464-1D4031544A1F@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C3AFA.8060908@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 14:52:36 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3AFA.8060908@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 21:52:36.0559 (UTC) FILETIME=[5A2FF5F0:01CA2A85] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1106; t=1251755557; x=1252619557; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Meanign=20of=20R=20bit |Sender:=20; bh=B3gHrPB0IKfVbpEZe5BD0qvaiZ+LX8j2C3tsbLabEgg=; b=RQLJjapGfd6T46cpnS1RbfvYFLK+aKR/e7xOat5xBrFizgc2Qy4luuF64O UtWb3L+PTV+BrQ7CzEroaw9gJlQFSoAFJxGcLpF+/sJWtQMEOkjXxFnC4sfU TzSbKsX3t7; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Meanign of R bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:52:33 -0000 > What is supposed to happen if an ETR receives a packet with an R bit > set to 1, and the N and L bits set to some combination other than 00? > Is that an error? The R-bit is allowed to user the other 2 fields as long as the enable- bits for each one is set to 0. > I would think it would make more sense to state that if the R bit is > set, the N and L bits are considered reserved, meaning that they > must be set to 0 on transmission, and ignored upon reception. Well, we *could* run with the R-bit to 1 and still do echo-noncing perhaps if the N bit is used. Since we are defining a bit for the future (and don't know how its going to be used -- which I don't like to do generally) it's hard to say how the Research header will work when the standard header is also being used. > That leaves us free to assign a meaning to the R bit, and decide > when we do so how to use the other two bits. We (Luigi, Damien, Noel, Andrew, Dave, Darrel, Vince, and Dino) talked about this but agreed to keep the semantics for each bit. Dino > > Yours, > Joel > From jmh@joelhalpern.com Mon Aug 31 14:59:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56F728C402 for ; Mon, 31 Aug 2009 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6-AdRdSNpGb for ; Mon, 31 Aug 2009 14:59:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0F8CE28C321 for ; Mon, 31 Aug 2009 14:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3046743068B; Mon, 31 Aug 2009 14:59:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C135743069A; Mon, 31 Aug 2009 14:59:49 -0700 (PDT) Message-ID: <4A9C47D5.20203@joelhalpern.com> Date: Mon, 31 Aug 2009 17:59:49 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3AFA.8060908@joelhalpern.com> <64D637CF-771E-465E-9464-1D4031544A1F@cisco.com> In-Reply-To: <64D637CF-771E-465E-9464-1D4031544A1F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Meanign of R bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 21:59:38 -0000 If setting the N or L bits is really illegal with the R bit, then shouldn't something talk about what error to generate upon reception? The other alternative is to simply treat the R bit itself as reserved, and stop talking about the interaction with the N and L bits until we define a use for the R bit. After all, if an ETR which doesn't know what the R bit is being used for receives a packet with it set, the only choices are to either ignore the setting or error the packet. Yours, Joel Dino Farinacci wrote: >> What is supposed to happen if an ETR receives a packet with an R bit >> set to 1, and the N and L bits set to some combination other than 00? >> Is that an error? > > The R-bit is allowed to user the other 2 fields as long as the > enable-bits for each one is set to 0. > >> I would think it would make more sense to state that if the R bit is >> set, the N and L bits are considered reserved, meaning that they must >> be set to 0 on transmission, and ignored upon reception. > > Well, we *could* run with the R-bit to 1 and still do echo-noncing > perhaps if the N bit is used. Since we are defining a bit for the future > (and don't know how its going to be used -- which I don't like to do > generally) it's hard to say how the Research header will work when the > standard header is also being used. > >> That leaves us free to assign a meaning to the R bit, and decide when >> we do so how to use the other two bits. > > We (Luigi, Damien, Noel, Andrew, Dave, Darrel, Vince, and Dino) talked > about this but agreed to keep the semantics for each bit. > > Dino > >> >> Yours, >> Joel >> > > From dino@cisco.com Mon Aug 31 15:12:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5854E3A6943 for ; Mon, 31 Aug 2009 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAaC4s60zaQm for ; Mon, 31 Aug 2009 15:12:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64A1128C51B for ; Mon, 31 Aug 2009 15:12:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF7nm0qrR7MV/2dsb2JhbADBdIhBAY8lBYQa X-IronPort-AV: E=Sophos;i="4.44,307,1249257600"; d="scan'208";a="379226627" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2009 22:12:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7VMCcs1017190; Mon, 31 Aug 2009 15:12:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7VMCcue002606; Mon, 31 Aug 2009 22:12:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:12:38 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:12:37 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C47D5.20203@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 15:12:36 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3AFA.8060908@joelhalpern.com> <64D637CF-771E-465E-9464-1D4031544A1F@cisco.com> <4A9C47D5.20203@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 22:12:37.0451 (UTC) FILETIME=[25F989B0:01CA2A88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1203; t=1251756758; x=1252620758; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Meanign=20of=20R=20bit |Sender:=20; bh=m5Diw23KePSM5dbPxVe8nPC+LOsyPoJahpV7v0qhnRU=; b=kgz8iCJ+ucCLKtsHGWM8cBx/uN4+uag4tuOtVBIL1msvE6NVWq+rGs6Hx+ UcysRyDIwSq1IYSLDpKFo9FeZCTkaYwCgQ2LxIBcob0FS8t2hZ9QqaMVQHlT X/4xhy25j4jUkc/xtmbYHU0nGSRSxj5wMmmlrqWboKrQqnPAVF1CQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Meanign of R bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 22:12:28 -0000 > If setting the N or L bits is really illegal with the R bit, then > shouldn't something talk about what error to generate upon reception? It's a question of which bit has preference over the other. The R-bit set is suppose to mean that the other fields can be used only when the N-bit is 0 and the L-bit is 0. But if either is set, the R-bit can define the field for the field which isn't enabled. That is N and L take preference over R. So the text as written is accurate. If a router that doesn't support the future defined functionality of the R-bit, can still look at the Nonce and Loc-Status- Bit fields when the R-bit is set. > The other alternative is to simply treat the R bit itself as > reserved, and stop talking about the interaction with the N and L > bits until we define a use for the R bit. After all, if an ETR > which doesn't know what the R bit is being used for receives a > packet with it set, the only choices are to either ignore the > setting or error the packet. And we believe it will be ignored. I don't have a strong feeling. Let the others who discussed this speak up to their preferences so we can converge. Dino From dmm@1-4-5.net Mon Aug 31 15:40:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1BB28C583 for ; Mon, 31 Aug 2009 15:40:54 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwbXjNaKTe3U for ; Mon, 31 Aug 2009 15:40:53 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D127328C5AC for ; Mon, 31 Aug 2009 15:40:53 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n7VMf5sf013405; Mon, 31 Aug 2009 15:41:05 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n7VMf5SC013404; Mon, 31 Aug 2009 15:41:05 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 31 Aug 2009 15:41:04 -0700 From: David Meyer To: "Joel M. Halpern" Message-ID: <20090831224104.GA13095@1-4-5.net> References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <4A9C3F31.20506@joelhalpern.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 22:40:54 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2009 at 05:22:57PM -0400, Joel M. Halpern wrote: > In the map reply, I am not sure I follow the reasoning for the "M" bit. = =20 > At a guess, it is intended for mobility cases. > As far as I can tell, it does not help. If the sender of the mapping =20 > data wants the receiver to validate the data frequently, then the sender = =20 > should use a short ttl. Joel, My original thinking was that the M-bit would be conveyed in the register message so that an ETR could tell the map-server that it needs to watch the RLOC(s) for this registration (because they might be changing more rapidly that the default behavior; a kind of hint). Its really more like of the negative of that; the M-bit tells the map-server that it might be able to suppress running a high(er) frequency locator-reachability algorithm for those registrations that *do not* have the bit set. However, the M-bit also is carried in a Map-Reply so you can convey the bit to an {I,P}TR for for the same reason (i.e., so an {I,P}TR could take advantage of the same "hint"). Dave --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqcUYAACgkQORgD1qCZ2KekfgCgjdoE9YyXtACjnZ6be6Dn8NGd xJMAoIYVfLD8yJ9JSqQyinATVwl0sNys =R3d7 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From jmh@joelhalpern.com Mon Aug 31 16:20:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9488F28C3C4 for ; Mon, 31 Aug 2009 16:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3HBk8EX6hE6 for ; Mon, 31 Aug 2009 16:20:15 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BE8BE3A6BCD for ; Mon, 31 Aug 2009 16:20:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 057FA4306A0; Mon, 31 Aug 2009 16:20:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7FB6D430687; Mon, 31 Aug 2009 16:20:27 -0700 (PDT) Message-ID: <4A9C5AB9.9010800@joelhalpern.com> Date: Mon, 31 Aug 2009 19:20:25 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Meyer References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> In-Reply-To: <20090831224104.GA13095@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 23:20:16 -0000 There are two kinds of locator liveness, I think. One kind is where the set of locators changes, in particular where new unanticipated locators are added to the set. The other kind of issue is where the connectivity of the RLOCs to the EID block is itnermittent / unreliable, and therefore should be monitored with probes or something similar. I guess the problem is that I assumed that "check for RLOC changes" (which is what the document says" would translate to the first kind, and would need to be done with map requests. The way a server tells the ITR to perform frequent map requests is with a short lifetime (TTL). Apparently, what you are suggesting is that this is intended as a hint for the second kind of issue / behavior. If so, please find clearer words for that. Yours, Joel David Meyer wrote: > On Mon, Aug 31, 2009 at 05:22:57PM -0400, Joel M. Halpern wrote: >> In the map reply, I am not sure I follow the reasoning for the "M" bit. >> At a guess, it is intended for mobility cases. >> As far as I can tell, it does not help. If the sender of the mapping >> data wants the receiver to validate the data frequently, then the sender >> should use a short ttl. > > Joel, > > My original thinking was that the M-bit would be conveyed > in the register message so that an ETR could tell the > map-server that it needs to watch the RLOC(s) for this > registration (because they might be changing more rapidly > that the default behavior; a kind of hint). Its really > more like of the negative of that; the M-bit tells the > map-server that it might be able to suppress running a > high(er) frequency locator-reachability algorithm for > those registrations that *do not* have the bit set. > > However, the M-bit also is carried in a Map-Reply so you > can convey the bit to an {I,P}TR for for the same reason > (i.e., so an {I,P}TR could take advantage of the same > "hint"). > > Dave > > From dino@cisco.com Mon Aug 31 16:40:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AB728C464 for ; Mon, 31 Aug 2009 16:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKUInCW5homE for ; Mon, 31 Aug 2009 16:40:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1ED1E28C27F for ; Mon, 31 Aug 2009 16:40:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGv8m0qrR7PD/2dsb2JhbADBaIhBAY89BYI/gVs X-IronPort-AV: E=Sophos;i="4.44,308,1249257600"; d="scan'208";a="379277778" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2009 23:40:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7VNeEUs028472; Mon, 31 Aug 2009 16:40:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7VNeEnF024969; Mon, 31 Aug 2009 23:40:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 16:40:14 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 16:40:13 -0700 Message-Id: <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C5AB9.9010800@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 16:40:13 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 Aug 2009 23:40:13.0783 (UTC) FILETIME=[62FE2670:01CA2A94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4179; t=1251762014; x=1252626014; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map-Reply=20M=20bit? |Sender:=20; bh=KPCc0fBHFInkfGquLBqlonctAsR4ZmRvgikyl/f5DzU=; b=ryIs4FfE3vZkRHKRs5G84buCYcF1n0FDsHkZjnVTHKgOlA/3jGF2Br24Mh 5qS4Zm7wh0MfcT8qjSlnXt2BYAX7oupkusGaRHOUbUC4LDY5OmStiBxeFHJD UfKU+1Ebre; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2009 23:40:03 -0000 > There are two kinds of locator liveness, I think. Locator liveness and mapping update changes are two different mechanisms. Locator liveness test the liveness of the locators in a locator-set of a map-cache entry. Locators are not removed from the locator-set when they become unreachable. Mapping update changes is done when a locator is added or removed or a priority or weight has changed for an existing locator. In the former case, when a LISP mobile-node moves a mapping update does the delete and add at the same time (when it is single-homed). A mapping update mechanism is achieved 3 ways (and 3 is needed to handle all the traffic directionality cases): (1) An ITR is RLOC-probing and a Map-Reply is returned with a different locator-set. The ITR replaces the information from what it had previously stored. (2) An ITR gets a Map-Request from the ETR and the ITR is configured to "ip lisp etr accept-map-request-mapping verify" (sorry to use cisco CLI syntax). In this case, a "verifying Map-Request" is sent by the ITR and a returning Map-Reply from the ETR replaces the locator-set stored. In this case, the ETR can be a MN that moves often and it has cleared its cache to who it is doing bidirectional communication with so the opportunity for the ITR to cache a mapping-update arises. (3) An ITR gets a SMR-based Map-Request which solicites the ITR to send a verifying Map-Request to use the procedures in (2). The final method is to have short TTLs where a normal EID-based Map- Request is sent. > One kind is where the set of locators changes, in particular where > new unanticipated locators are added to the set. The other kind of > issue is where the connectivity of the RLOCs to the EID block is > itnermittent / unreliable, and therefore should be monitored with > probes or something similar. Right, two completely separated problems and solutions we have to them. > I guess the problem is that I assumed that "check for RLOC > changes" (which is what the document says" would translate to the > first kind, and would need to be done with map requests. The way a > server tells the ITR to perform frequent map requests is with a > short lifetime (TTL). Let's refer to this terminology wise as "mapping updates". Luigi coined the phrase, so I kept using it. We use the term "locator reachability" for the other problem space. > Apparently, what you are suggesting is that this is intended as a > hint for the second kind of issue / behavior. If so, please find > clearer words for that. No, that is not what I think Dave meant. Dave to clarify. But I think he just was referring how to do mapping-updates with method (1) above. That is, if you are testing locator reachability with a Map-Request/ Map-Reply exchange, you not only get an ack to the request but you get a fresh mapping-update at the same time. Dino > > Yours, > Joel > > David Meyer wrote: >> On Mon, Aug 31, 2009 at 05:22:57PM -0400, Joel M. Halpern wrote: >>> In the map reply, I am not sure I follow the reasoning for the "M" >>> bit. At a guess, it is intended for mobility cases. >>> As far as I can tell, it does not help. If the sender of the >>> mapping data wants the receiver to validate the data frequently, >>> then the sender should use a short ttl. >> Joel, >> My original thinking was that the M-bit would be conveyed >> in the register message so that an ETR could tell the >> map-server that it needs to watch the RLOC(s) for this >> registration (because they might be changing more rapidly >> that the default behavior; a kind of hint). Its really >> more like of the negative of that; the M-bit tells the >> map-server that it might be able to suppress running a >> high(er) frequency locator-reachability algorithm for >> those registrations that *do not* have the bit set. >> However, the M-bit also is carried in a Map-Reply so you >> can convey the bit to an {I,P}TR for for the same reason >> (i.e., so an {I,P}TR could take advantage of the same >> "hint"). >> Dave From dmm@1-4-5.net Mon Aug 31 17:05:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4FB3A69E7 for ; Mon, 31 Aug 2009 17:05:55 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h4MymHdKGKE for ; Mon, 31 Aug 2009 17:05:55 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id DCDF23A6B84 for ; Mon, 31 Aug 2009 17:05:54 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n81060Is015816; Mon, 31 Aug 2009 17:06:00 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n81060Ap015815; Mon, 31 Aug 2009 17:06:00 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 31 Aug 2009 17:06:00 -0700 From: David Meyer To: Dino Farinacci Message-ID: <20090901000600.GA15769@1-4-5.net> References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:05:55 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > No, that is not what I think Dave meant. Dave to clarify. But I think he= =20 > just was referring how to do mapping-updates with method (1) above. Yes. Dino's language was much clearer than mine. Dave --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqcZWgACgkQORgD1qCZ2Kc2mgCaA6vnSTZrX/zpvfoVMxMFHR/c NyYAnjVQZUguu+DQFuE+vOSBR5Q251Ct =ri/r -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From jmh@joelhalpern.com Mon Aug 31 17:13:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984383A69E1 for ; Mon, 31 Aug 2009 17:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnTdNarWgfPQ for ; Mon, 31 Aug 2009 17:13:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id ED7723A6933 for ; Mon, 31 Aug 2009 17:13:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 51A314306AB; Mon, 31 Aug 2009 17:13:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B74AC4306A0; Mon, 31 Aug 2009 17:13:20 -0700 (PDT) Message-ID: <4A9C671F.2010209@joelhalpern.com> Date: Mon, 31 Aug 2009 20:13:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> In-Reply-To: <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:13:09 -0000 After some discussion of-line, I will simplify my request. If the text is intended, as I believe from the discussion, to be talking about locator liveness monitoring, and the frequency with which that is done, then please 1) Say that. "RLOC changes" which is the current document wording says leads at least some readers (me) to look for changes in the RLOC set, not changes in the RLOC liveness. 2) Please be more explicit about what the receiver is supposed to do when the bit is set. If I were trying to implement taht text, I would be guessing as to what I am supposed to do in relation to seeing the M bit set or clear in a response. Should this control probing? Should it multiply the probing rate by a factor? (If so what factor?) Should I just ignore it because I do not know what conditions would cause the sender to set the bit? Yours, Joel From dino@cisco.com Mon Aug 31 17:29:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718B93A6BF0 for ; Mon, 31 Aug 2009 17:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIGitX4TRIC4 for ; Mon, 31 Aug 2009 17:29:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3F5D028C0E7 for ; Mon, 31 Aug 2009 17:27:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPcGnEqrR7MV/2dsb2JhbADBeIhBAY9CBYQa X-IronPort-AV: E=Sophos;i="4.44,308,1249257600"; d="scan'208";a="379307108" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 00:28:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n810S6pj020591; Mon, 31 Aug 2009 17:28:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n810S6Xs029201; Tue, 1 Sep 2009 00:28:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:28:06 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:28:05 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C671F.2010209@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 17:28:05 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 00:28:06.0096 (UTC) FILETIME=[13065500:01CA2A9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1408; t=1251764886; x=1252628886; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map-Reply=20M=20bit? |Sender:=20; bh=Tp/mL4x5Zi/jS+pj4FX/7cTgiJjYBEpkDZ2zAxZOUNY=; b=h45g6NAY75pyDiFI6KApcH5SRWyoF1BXERHG6XAcL8KFfDPdSKIHrhcT0+ M0ZtyCUV3RhIZZQD4EUwI91zYUH9uXAVfVhCGDPZxfxuDHcVSO7LYr1sLA6+ gbo0HdlKniBcW+pkt5m+3Usu8OiUUewWDMQDSAQ03V2OBgnryiKGY=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:29:15 -0000 > After some discussion of-line, I will simplify my request. > > If the text is intended, as I believe from the discussion, to be > talking about locator liveness monitoring, and the frequency with > which that is done, then please The M-bit setting is not talking about that. > 1) Say that. "RLOC changes" which is the current document wording > says leads at least some readers (me) to look for changes in the > RLOC set, not changes in the RLOC liveness. There is still confusion. The M-bit is there because we want to use if for LISP-MN. We will spec out the usage in a future draft-meyer-lisp- mn draft. We are allocating the bit in the main LISP draft. So we can't be precise right now. > 2) Please be more explicit about what the receiver is supposed to do > when the bit is set. If I were trying to implement taht text, I > would be guessing as to what I am supposed to do in relation to > seeing the M bit set or clear in a response. Should this control > probing? Should it multiply the probing rate by a factor? (If so > what factor?) Should I just ignore it because I do not know what > conditions would cause the sender to set the bit? We will in a future LISP-MN spec update. This spec is not focusing on MN as focus on the main charter. We allocate the bit to hold a spot for it. That is why the description is vague. Dino From jmh@joelhalpern.com Mon Aug 31 17:45:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C32B3A6C37 for ; Mon, 31 Aug 2009 17:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3bJ3ijc9dMP for ; Mon, 31 Aug 2009 17:45:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F102B3A69E1 for ; Mon, 31 Aug 2009 17:45:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 492874306A5; Mon, 31 Aug 2009 17:46:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C40BC4306A4; Mon, 31 Aug 2009 17:46:04 -0700 (PDT) Message-ID: <4A9C6ECB.4040105@joelhalpern.com> Date: Mon, 31 Aug 2009 20:46:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:45:53 -0000 Then say "This bit is for reserved for future usage by a LISP Mobility Solution." Having a bit in a spec that is described as doing something, but actually doesn't do that, is no help. Yours, Joel Dino Farinacci wrote: >> After some discussion of-line, I will simplify my request. >> >> If the text is intended, as I believe from the discussion, to be >> talking about locator liveness monitoring, and the frequency with >> which that is done, then please > > The M-bit setting is not talking about that. > >> 1) Say that. "RLOC changes" which is the current document wording >> says leads at least some readers (me) to look for changes in the RLOC >> set, not changes in the RLOC liveness. > > There is still confusion. The M-bit is there because we want to use if > for LISP-MN. We will spec out the usage in a future draft-meyer-lisp-mn > draft. We are allocating the bit in the main LISP draft. So we can't be > precise right now. > >> 2) Please be more explicit about what the receiver is supposed to do >> when the bit is set. If I were trying to implement taht text, I would >> be guessing as to what I am supposed to do in relation to seeing the M >> bit set or clear in a response. Should this control probing? Should >> it multiply the probing rate by a factor? (If so what factor?) Should >> I just ignore it because I do not know what conditions would cause the >> sender to set the bit? > > We will in a future LISP-MN spec update. This spec is not focusing on MN > as focus on the main charter. We allocate the bit to hold a spot for it. > That is why the description is vague. > > Dino > > From dino@cisco.com Mon Aug 31 17:47:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90753A69E1 for ; Mon, 31 Aug 2009 17:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9LTYx1whGcj for ; Mon, 31 Aug 2009 17:47:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0739A3A66B4 for ; Mon, 31 Aug 2009 17:47:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKcLnEqrR7MV/2dsb2JhbADBWohBAY9CBYQa X-IronPort-AV: E=Sophos;i="4.44,308,1249257600"; d="scan'208";a="379316438" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 00:47:49 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n810lnBh008266; Mon, 31 Aug 2009 17:47:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n810lnci015498; Tue, 1 Sep 2009 00:47:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:47:48 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:47:48 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C6ECB.4040105@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 17:47:48 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> <4A9C6ECB.4040105@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 00:47:48.0752 (UTC) FILETIME=[D3F15100:01CA2A9D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=258; t=1251766069; x=1252630069; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map-Reply=20M=20bit? |Sender:=20; bh=wsrv3R69ZGMYdeVILkG86g2XNMsNABEE3DjQ2amH1FU=; b=q1bcYDrFtH7L+rxQy9v2MmEGMV1VQOLatbQmx2hycZ/O+PayQ0hGKybea5 MKuTkvVXWHxpz/WrgAONRbb5bZDXoeJxT+mTkTn+W1L6ES8cfWz1jaIK2yIf R0RAi9UT7d/O24wcGarJwNgHWJVxtOIksEF3DeLUqYJPiRBLV6384=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:47:37 -0000 > hen say "This bit is for reserved for future usage by a LISP > Mobility Solution." Having a bit in a spec that is described as > doing something, but actually doesn't do that, is no help. Great suggestion. I will do that. Thanks Joel! Dino From jmh@joelhalpern.com Mon Aug 31 17:47:54 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5863A6EDE for ; Mon, 31 Aug 2009 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzBIcHFbOc3N for ; Mon, 31 Aug 2009 17:47:53 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AC5903A6ED0 for ; Mon, 31 Aug 2009 17:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 237EE4306AB; Mon, 31 Aug 2009 17:48:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9EFB44306A5; Mon, 31 Aug 2009 17:48:05 -0700 (PDT) Message-ID: <4A9C6F44.1000306@joelhalpern.com> Date: Mon, 31 Aug 2009 20:48:04 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:47:54 -0000 My last reply said "then reserve it for Mobility." However, immediately after I sent that I realized that I at least suspect that we will end up with a solution that doe snot need a bit with that meaning. So, rather than trying to guess, just mark the bit as reserved (must be 0 on transmission and ignored on reception.) Then, if we decide to use it for something specific later, we can. And if we don't use it for that, then it is available for some other use. Yours, Joel Dino Farinacci wrote: >> After some discussion of-line, I will simplify my request. >> >> If the text is intended, as I believe from the discussion, to be >> talking about locator liveness monitoring, and the frequency with >> which that is done, then please > > The M-bit setting is not talking about that. > >> 1) Say that. "RLOC changes" which is the current document wording >> says leads at least some readers (me) to look for changes in the RLOC >> set, not changes in the RLOC liveness. > > There is still confusion. The M-bit is there because we want to use if > for LISP-MN. We will spec out the usage in a future draft-meyer-lisp-mn > draft. We are allocating the bit in the main LISP draft. So we can't be > precise right now. > >> 2) Please be more explicit about what the receiver is supposed to do >> when the bit is set. If I were trying to implement taht text, I would >> be guessing as to what I am supposed to do in relation to seeing the M >> bit set or clear in a response. Should this control probing? Should >> it multiply the probing rate by a factor? (If so what factor?) Should >> I just ignore it because I do not know what conditions would cause the >> sender to set the bit? > > We will in a future LISP-MN spec update. This spec is not focusing on MN > as focus on the main charter. We allocate the bit to hold a spot for it. > That is why the description is vague. > > Dino > > From dino@cisco.com Mon Aug 31 17:53:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505243A6A84 for ; Mon, 31 Aug 2009 17:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJk5GGGlrfKi for ; Mon, 31 Aug 2009 17:53:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8FB0D3A66B4 for ; Mon, 31 Aug 2009 17:53:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANMMnEqrR7PE/2dsb2JhbADBWIhBAY9CBYQa X-IronPort-AV: E=Sophos;i="4.44,308,1249257600"; d="scan'208";a="379318905" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 00:53:36 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n810raUq014916; Mon, 31 Aug 2009 17:53:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n810rX5T015038; Tue, 1 Sep 2009 00:53:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:53:29 -0700 Received: from [192.168.1.4] ([10.21.85.224]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 17:53:29 -0700 Message-Id: <224C489C-6E82-4ED8-9134-DC1EF69AFD78@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4A9C6F44.1000306@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 31 Aug 2009 17:53:29 -0700 References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> <4A9C6F44.1000306@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 01 Sep 2009 00:53:29.0412 (UTC) FILETIME=[9EFDE840:01CA2A9E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=640; t=1251766416; x=1252630416; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map-Reply=20M=20bit? |Sender:=20; bh=uBnJVS3w6sT58n69LnPY5QG2kUbCKTo3LrBwZI23WLg=; b=p9lwrfGBz+j0+C1vxuS8qWeqjbJufDidlfr6JO0CVPKw51ras1IY30D/VT chmBKPQYg9L7RS6SOphKF4H96Op/YQQ4Jz/++D2PGISVVxsuuN68YxFgOZaP YppbfK0hoH; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 00:53:25 -0000 > My last reply said "then reserve it for Mobility." > However, immediately after I sent that I realized that I at least > suspect that we will end up with a solution that doe snot need a bit > with that meaning. > > So, rather than trying to guess, just mark the bit as reserved (must > be 0 on transmission and ignored on reception.) Then, if we decide > to use it for something specific later, we can. And if we don't use > it for that, then it is available for some other use. How about this: M: this bit is reserved for use by the LISP mobile-node design documented in [LISP-MN]. Okay? Dino From jmh@joelhalpern.com Mon Aug 31 18:08:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D32E3A6D27 for ; Mon, 31 Aug 2009 18:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc2XjzJ7Osz8 for ; Mon, 31 Aug 2009 18:08:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 204613A689D for ; Mon, 31 Aug 2009 18:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8E63D4306AC; Mon, 31 Aug 2009 18:08:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.9] (pool-173-59-34-176.phlapa.fios.verizon.net [173.59.34.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 18EF34306A5; Mon, 31 Aug 2009 18:08:50 -0700 (PDT) Message-ID: <4A9C7420.1050500@joelhalpern.com> Date: Mon, 31 Aug 2009 21:08:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <643940D7-D234-4E67-BC5E-F5DF3D078D83@cisco.com> <4A9C3F31.20506@joelhalpern.com> <20090831224104.GA13095@1-4-5.net> <4A9C5AB9.9010800@joelhalpern.com> <79968FDE-1588-4BF0-BB4C-211E38DD9058@cisco.com> <4A9C671F.2010209@joelhalpern.com> <4A9C6F44.1000306@joelhalpern.com> <224C489C-6E82-4ED8-9134-DC1EF69AFD78@cisco.com> In-Reply-To: <224C489C-6E82-4ED8-9134-DC1EF69AFD78@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Reply M bit? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2009 01:08:42 -0000 I can live with it. It does mean that if we don't use it there, the base spec will need to be revised in order to use that bit for something else. But that is much better than what is there currently. Joel Dino Farinacci wrote: >> My last reply said "then reserve it for Mobility." >> However, immediately after I sent that I realized that I at least >> suspect that we will end up with a solution that doe snot need a bit >> with that meaning. >> >> So, rather than trying to guess, just mark the bit as reserved (must >> be 0 on transmission and ignored on reception.) Then, if we decide to >> use it for something specific later, we can. And if we don't use it >> for that, then it is available for some other use. > > How about this: > > M: this bit is reserved for use by the LISP mobile-node design > documented in [LISP-MN]. > > Okay? > > Dino > >